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Commissioner for Patents: 

This Appellant's Brief is being filed under 37 CFR 41.37 (effective date of 
September 13, 2004) in furtherance of the Notice of Appeal, filed in this case on November 3, 
2009. The fees required under Section 1.17(c), and any required request for an extension of time 
for filing this Appellant's Brief and fees therefor, are dealt with in the accompanying papers. 

I. REAL PARTY IN INTEREST 

Foundry Networks, Inc. is the real party in interest. On December 19, 2008, 
Brocade Communications Systems, Inc. acquired Foundry Networks, Inc. Foundry Networks, 
Inc. became a wholly-owned subsidiary of Brocade Communications Systems, Inc. 

Subsequently, Foundry Networks, Inc.'s name/form was changed to Foundry Networks LLC, but 
it remains a wholly-owned subsidiary of Brocade Communications Systems, Inc. 
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II. 



RELATED APPEALS AND INTERFERENCES 



An appeal (Appeal No. 2009-011505) is currently pending in U.S. Patent 
Application Serial No. 10/305,823, which is also assigned to Foundry Networks, Inc. and which 
discloses some subject matter that is in common with some of the subject matter disclosed in the 
present U.S. Patent Application Serial No. 10/674,627 (hereinafter referred to as "the present 
application"). A decision on said currently pending appeal has not yet been rendered as of the 
filing of this Appellant's Brief 

III. STATUS OF CLAIMS 

Claims 34-38, 43-46, 51-55, and 60-74 are pending and stand finally rejected by 
the final Office Action mailed August 3, 2009 (hereinafter referred to as "the final Office Action 
of August 3, 2009") and by the Advisory Action mailed October 16, 2009 (hereinafter referred to 
as "the Advisory Action of October 16, 2009"). 

Claims 1-33, 39-42, 47-50, and 56-59 have been previously canceled. 

No claims are allowed or objected to. 

The rejections of claims 34-38, 43-46, 51-55, and 60-74 are being appealed herein. 

IV. STATUS OF AMENDMENTS 

There are no outstanding amendments. 

A response under 37 CFR 1.116 was filed September 21, 2009 that amended 
independent claim 34 (to add a punctuation mark/period at the end of the claim), so as to address 
an objection raised in the final Office Action of August 3, 2009. 

The Advisory Action of October 16, 2009 indicated that said response filed on 
September 21, 2009 was entered, and so it is believed that the objection to claim 34 has now been 
withdrawn. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

According to one or more embodiments disclosed in the present application and to 
which the claimed subject matter is directed, there is provided a load balance switch [100, 200, 
300 in Figures 1-4] and a plurality of site switches [108, 208, 308 in Figures 1-4] that are each 
adapted to couple at least one host server [110, 210, 310 in Figures 1-4] to a network [104 in 
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Figures 1-4]. Mapping information is obtained at one of the site switches {page 4, line 10; page 
6, line 12; page 8, line 26; 600 in Figure 6; 700 in Figure 7]. The mapping information provides 
a translation between a private virtual IP address, configured at the site switch and associated with 
the host server corresponding to the site switch, and a public virtual IP address [page 2, lines 19- 
22; page 7, lines 23-26; page 9, lines 19-20 and line 26; page 13, lines 4-6; 502 in Figure 5]. 
The site switch provides the public virtual IP address {222 in Figure 2; page 10, lines 17-20; 316 
in Figures 3-4; page 13, lines 9-11; 508 in Figure 5; 602 and 606 in Figure 6; 702 and 708 in 
Figure 7] to at least one load balancing controller {100, 200, 300 in Figures 1-4; 318 in Figures 
3-4; 602 and 606 in Figure 6; 702 and 708 in Figure 7]. 

According to one embodiment, the load balancing controller is located at the load 
balancing switch {100, 200, 300 in Figures 1-4]. According to one embodiment, the load 
balancing controller {318 in Figures 5-4] is located at the site switch. 

The disclosed embodiment(s) address at least one drawback found in conventional 
load balancing systems, wherein the global server load balancing (GSLB) switch receives from 
the site switches a list of virtual IP addresses (VIPs) configured at the site switches. If these VIPs 
configured on the site switch are private IP addresses mapped to public IP addresses by a device 
such as a firewall or NAT device, then the site switch is unaware of the mapping and only 
communicates the private VIP addresses to the GSLB switch. The GSLB switch in turn would 
not be able to correctly apply load balancing metrics, since the metrics and GSLB switch's 
appUcation of the metrics are designed to work with public VIP addresses, rather than private VIP 
addresses. See, e.g., page 2, line 19 to page 4, line 7 of the present application. 

The following discusses independent claims 34, 43, 51, 63, 67, and 71. According 
to 37 CFR 41.37(c)(l)(v), a concise explanation of the subject matter in the independent claims 
"involved in the appeal" has been set forth below with reference to the specification by page and 
line niimbers, and to the drawings, if any, by reference characters. Accordingly, the following 
shows claims 34, 43, 51, 63, 67, and 71 together with the required reference information in 
brackets [ ] and italicized. Of course, the reference numbers and other bracketed information are 
illustrative only and are not intended to limit the claims only to the exact embodiments shown and 
described in the specification and figures of the present application. 
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34. A method [Figures 5-7] of providing load balancing usable with a load 
balance switch [100, 200, 300 in Figures 1-4] and a plurality of site switches [108, 208, 308 in 
Figures 1-4] that are each adapted to couple at least one host server {110, 210, 310 in Figures 1- 
4] to a network {104 in Figures 1-4], the method comprising: 

obtaining at one of said site switches mapping information {page 4, line 10; page 

6, line 12; page 8, line 26; 600 in Figure 6; 700 in Figure 7] that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address {page 2, lines 19-22; page 

7, lines 23-26; page 9, lines 19-20 and line 26; page 13, lines 4-6; 502 in Figure 5]; and 

providing, by said site switch, said public virtual IP address {222 in Figure 2; page 
10, lines 17-20; 316 in Figures 3-4; page 13, lines 9-11; 508 in Figure 5; 602 and 606 in Figure 
6; 702 and 708 in Figure 7] to at least one load balancing controller {100, 200, 300 in Figures 1- 
4; 318 in Figures 3-4; 602 and 606 in Figure 6; 702 and 708 in Figure 7]. 

43. An article of manufacture, comprising: 

a storage medium [page 10, line 24 to page 11, line 5; page 25, line 15] at a site 
switch [108, 208, 308 in Figures 1-4] and having instructions stored thereon that are executable 
by said site switch to enable load balancing {Figures 5-7], by: 

obtaining at said site switch mapping information {page 4, line 10; page 6, line 12; 
page 8, line 26; 600 in Figure 6; 700 in Figure 7] that provides a translation between a private 
virtual IP address and a public virtual IP address, said private virtual IP address being configured 
at said site switch and being associated with at least one host server corresponding to said site 
switch {page 2, lines 19-22; page 7, lines 23-26; page 9, lines 19-20 and line 26; page 13, lines 4- 
6; 502 in Figure 5]; and 

providing, by said site switch, said public virtual IP address {222 in Figure 2; page 
10, lines 17-20; 316 in Figures 3-4; page 13, lines 9-11; 508 in Figure 5; 602 and 606 in Figure 
6; 702 and 708 in Figure 7] to at least one load balancing controller {100, 200, 300 in Figures 1- 
4; 318 in Figures 3-4; 602 and 606 in Figure 6; 702 and 708 in Figure 7]. 

51. A network device, comprising: 
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a site switch [108, 208, 308 in Figures 1-4] configurable with a private virtual IP 
address associated with at least one host server corresponding to said site switch {page 9, lines 19- 
20 and line 26; page 13, lines 4-6]; and 

a component [318 in Figures 3-4; page 16, lines 5-6] in said site switch to obtain a 
pubUc virtual IP address translated from said private virtual IP address [page 2, lines 19-22; page 
7, lines 23-26; 502 in Figure 5], 

wherein said site switch is adapted to provide said obtained public virtual IP 
address [222 in Figure 2; page 10, lines 17-20; 316 in Figures 3-4; page 13, lines 9-11; 508 in 
Figure 5; 602 and 606 in Figure 6; 702 and 708 in Figure 7] to at least one load balancing 
controller [100, 200, 300 in Figures 1-4; 318 in Figures 3-4; 602 and 606 in Figure 6; 702 and 
708 in Figure 7]. 

63. A method [Figures 5-7] of providing load balancing, the method 

comprising: 

identifying [page 6, lines 12-13; page 4, line 10; page 6, line 12; page 8, line 26; 
600 in Figure 6; 700 in Figure 7], by a switch [108, 208, 308 in Figures 1-4], a public virtual IP 
address that is mapped to a private virtual IP address configured at the switch [page 2, lines 19- 
22; page 7, lines 23-26; page 9, lines 19-20 and line 26; page 13, lines 4-6; 502 in Figure 5]; and 

communicating, by the switch to a load balancing controller [100, 200, 300 in 
Figures 1-4; 318 in Figures 3-4; 602 and 606 in Figure 6; 702 and 708 in Figure 7], the 
identified public virtual IP address [222 in Figure 2; page 10, lines 17-20; 316 in Figures 3-4; 
page 13, lines 9-11; 508 in Figure 5; 602 and 606 in Figure 6; 702 and 708 in Figure 7]. 

67. An article of manufacture, comprising: 

a storage medivim [page 10, line 24 to page 11, line 5; page 25, line 75] at a switch 
[108, 208, 308 in Figures 1-4] and having instructions stored thereon that are executable by the 

switch to: 

identify [page 6, lines 12-1 3; page 4, line 10; page 6, line 12; page 8, line 26; 600 
in Figure 6; 700 in Figure 7], by the switch, a public virtual IP address that is mapped to a private 
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virtual IP address configured at the switch [page 2, lines 19-22; page 7, lines 23-26; page 9, lines 
19-20 and line 26; page 13, lines 4-6; 502 in Figure 5]; and 

communicate, by the switch to a load balancing controller [100, 200, 300 in 
Figures 1-4; 318 in Figures 3-4; 602 and 606 in Figure 6; 702 and 708 in Figure 7], the 
identified public virtual IP address [222 in Figure 2; page 10, lines 17-20; 316 in Figures 3-4; 
page 13, lines 9-11; 508 in Figure 5; 602 and 606 in Figure 6; 702 and 708 in Figure 7]. 

71. A network device, comprising: 

a switch [108, 208, 308 in Figures 1-4] configurable with a private virtual IP 
address [page 9, lines 19-20 and line 26; page 13, lines 4-6], the switch being adapted to identify 
[page 6, lines 12-13; page 4, line 10; page 6, line 12; page 8, line 26; 600 in Figure 6; 700 in 
Figure 7] a public virtual IP address that is mapped to the private virtual IP address configured at 
the switch [page 2, lines 19-22; page 7, lines 23-26; page 9, lines 19-20 and line 26; page 13, 
lines 4-6; 502 in Figure 5], and the switch being adapted to communicate the identified public 
virtual IP address to a load balancing controller [100, 200, 300 in Figures 1-4; 318 in Figures 3- 
4; 602 and 606 in Figure 6; 702 and 708 in Figure 7; 222 in Figure 2; page 10, lines 17-20; 316 
in Figures 3-4; page 13, lines 9-11; 508 in Figure 5]. 

37 CFR41.37(c)(l)(v) requires that "For each independent claim involved in the 
appeal and for each dependent claim argued separately under the provisions of paragraph 

(c)(l)(vii) of this section, every means plus function and step plus function as permitted by 
35 U.S.C. 112, sixth paragraph, must be identified and the structure, material, or acts described in 
the specification as corresponding to each claimed function must be set forth with reference to the 
specification by page and line number, and to the drawing, if any, by reference characters." There 
are no means plus flinction or step plus flinction elements in the claims being appealed herein for 
which this requirement applies. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 34-38, 43-46, 51-55, and 60-74 are anticipated under 35 U.S.C. 
§ 102(b) by a white paper entitled "Server Load Balancing in Today's Web-Enabled Enterprise" 
(hereinafter referred to as "the White Paper"). 

Whether claims 34-38, 43-46, 51-55, and 60-74 are unpatentable under 35 U.S.C. 
§ 103(a) over an Alteon document entitled "Enhancing Web User Experience v^^ith Global Server 
Load Balancing" (hereinafter referred to as "the Alteon document") in view of a Cisco document 
entitled "Configuring the CSS Domain Name Server" (hereinafter referred to as "the Cisco 
document"). 

VII. ARGUMENT 

A. The rejected claims are patentable under Section 102 over the White 

Paper 

In explaining novelty under 35 U.S.C. § 102, MPEP § 2131 states that "A claim is 
anticipated only if each and every element as set forth in the claim is found, either expressly or 
inherently described, in a single prior art reference," citing Verdegaal Bros. v. Union Oil Co. of 
California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). 

The Examiner's rejection of independent claims 34, 43, 51, 63, 67, and 71 and 
their respective dependent claims as being anticipated by the White Paper is improper. As will be 
explained next below, independent claims 34, 43, 51, 63, 67, and 71 and their respective 
dependent claims recite elements that are not described expressly or inherently in the White 
Paper, and as such, there is no support for the Examiner's position that the claims are anticipated 
by the White Paper. 

/. Independent claim 34 is not anticipated by the White Paper 
Independent claim 34 recites, inter alia, the following (emphasis ours): 

"obtaining at one of said site switches mapping information that provides 
a translation between a private virtual IP address, configured at said site switch 
and associated with said at least one host server corresponding to said site switch, 
and a public virtual IP address; and 
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providing, by said site switch, said public virtual IP address to at least 
one load balancing controller ^ 

The White Paper does not teach such recitations of claim 34. 

In rejecting claim 34, the final Office Action of August 3, 2009 as well as previous 
Office Actions have continued to rely upon the Figure and accompanying description provided on 
page 6 of the White Paper. The Figure and accompanying description on page 6 et seq. of the 
White Paper show a global server load balancing (GSLB) system that existed prior to the present 
inventor's invention. The GSLB system in the Figure and page 6 et seq. of the White Paper 
provide a GSLB switch (referred to as a "CGS" or controller GSLB switch) and site switches that 
communicate with the GSLB switch. 

However, evidence and arguments against the Examiner have been submitted 
during prosecution that such GSLB system of the White Paper does not teach the recitations of 
claim 34 of "providing, by said site switch, said public virtual IP address to at least one load 
balancing controller" where "a private virtual IP address [is] configured at said site switch." 

Specifically, evidence in the form of affidavits executed by Ms. Prajakta S. Joshi 
(the inventor named in the present application) have been submitted during prosecution to show 
that the White Paper does not teach the claimed subject matter, such as recited in claim 34. See, 
e.g., the Evidence Appendix of this Appellant's Brief (Exhibit A: Ms. Joshi's affidavit executed 
on October 2, 2008, and Exhibit B: Ms. Joshi's affidavit executed on January 29, 2008). 

In making reference to Ms. Joshi's affidavit executed on October 2, 2008 (Exhibit 
A), pages 13-14 of the Remarks section of the amendment/response filed on October 7, 2008 
explained the following (emphasis ours): 

"As stated in the affidavit by Ms. Joshi, who is knowledgeable of the 
subject matter described in the White Paper, _/or an architecture where a private 
virtual IP address was configured at the site switch, the site switch did not 
communicate public virtual IP addresses to the controller GSLB switch (CGS) 
of the White Paper, prior to her invention. Instead for an architecture where a 
private virtual IP address was configured at the site switch, the private virtual 
IP address (rather than a public virtual IP address) was communicated by the 
site switch to the CGS of the White Paper. With the embodiments of her 
invention, the site switch obtained (from a mapping device such as a NAT device 
or a firewall device) the mapping information that provides a translation between 
the private virtual IP address and the public virtual IP address, thereby enabling 
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the site switch to provide this pubic virtual IP address to the load balancing 
controller." 

Sections 8-10 and Figure A of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides further specific details/examples of the manner in which the site switch of 
the White Paper communicates the private VIP address (rather than the public VIP address) to the 
controller GSLB switch, for an architecture where the private VIP address is configured at the site 
switch. In comparison, sections 11-12 and Figure B of Ms. Joshi's affidavit executed on October 
2, 2008 (Exhibit A) provides fiirther specific details/examples of an embodiment of her invention 
that involves (emphasis ours): "obtaining at one of said site switches mapping information that 
provides a translation between a private virtual IP address, configured at said site switch and 
associated with said at least one host server corresponding to said site switch, and a public virtual 
IP address; and providing, by said site switch, said public virtual IP address to at least one load 
balancing controller. " 

Sections 8-11 of Ms. Joshi's affidavit executed on January 29, 2008 (Exhibit B) 
provides further explanation that the GSLB technology of the White Paper does not include the 
implementation of her invention as claimed in the present application. Ms. Joshi explains that in 
the GSLB technology of the White Paper, the site switch would "communicate the private VIP 
address configured thereon" to the controller GSLB switch or "CGS" shown in Figure on page 6 
of the White Paper, and such communication of the private VIP address would cause certain 
problems. Thus, Ms. Joshi invented her invention in order to address such problems of the GSLB 
technology of the White Paper. 

The Examiner has not provided any evidence or plausible arguments to rebut the 
specific evidence provided in Ms. Joshi's affidavits (her evidence showing that the GSLB 
technology of the White Paper does not teach the recitations of claim 34). Instead of specifically 
articulating arguments against the evidence provided in Ms. Joshi's affidavits, the Examiner has 
simply and broadly reflised to give such Affidavits due weight, by continuously asserting that 
since the White Paper was being used as a reference under 35 U.S.C. § 102(b), no affidavit of any 
kind whatsoever can be used to overcome the White Paper. See, e.g., page 2 (section 2) of the 
Office Action mailed December 23, 2008 (wherein the Examiner states "An Affidavit/Declaration 
cannot be used to disqualify a reference which is a statutory bar. . .), pages 2-3 (section 3) of the 
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final Office Action of August 3, 2009 (wherein the Examiner interprets, incorrectly, that Ms. 
Joshi's affidavit executed on October 2, 2008 is an attempt to show that the subject matter in the 
cited references is derived from the present inventor), and the last sentence in the continuation 
sheet of the Advisory Action of October 16, 2009 (wherein the Examiner states "the affidavit 
cannot be used to overcome the reference that is the 102(b) type"). 

The Examiner's blanket refusal to give the evidence in Ms. Joshi's affidavit(s) due 
weight, simply because the White Paper is being applied as a 102(b) reference, is without merit. 
For example, the following explanation was provided in the response filed on September 21, 2009 
to address the final Office Action of August 3, 2009: 

"In response to this previously submitted affidavit, page 2 (section 3) of 
the present final Office Action stated the following (emphasis in original): 

'It should be noted that the traversal using 37 CFR 1.132 is 
to rebut a rejection under 35 USC 102(a) type (emphasis added): 
i.e., an affidavit under 37 CFR 1.132 shows that the inventorship 
of the application is correct in that the reference discloses subject 
matter derived from the applicant rather than invented by the 
author. . .notwithstanding the authorship of the article... The White 
Paper is a statutory bar reference under 35 USC 102(b). The 
reference of [Alteon in view of the Cisco Document] both appear 
not being derived from the inventorship of the apphcation.' 

The above-quoted statement(s) from the final Office Action again 
represents a misimderstanding by the Examiner of the purpose and content of the 

previously filed affidavit. The Examiner seems to be interpreting the previously 
filed affidavit in accordance with MPEP § 716.10 that discusses an affidavit filed 
under 37 CFR 1.132 to show 'attribution' (e.g., an affidavit to show that the 
relevant portions of the reference originated with or were obtained from 
applicant). 

However, as clearly set forth by the other sub-sections 716.01-716.09 of 
MPEP § 716, the 'attribution' of MPEP § 716.10 is not the sole basis for filing an 
affidavit under 37 CFR 1.132. Indeed, the previously filed affidavit was not 
intended to present an 'attribution' argument. Rather, the previously filed 
affidavit under 37 CFR 1.132 was submitted to present evidence to traverse the 
rejection, or more particularly as specified in MPEP § 716 (emphasis ours): 

'716 Affidavits or Declarations Traversing Rejections, 37 
CFR 1.132 
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37 CFR 1.132 Affidavits or declarations traversing 
rejections or objections. 

When any claim of an application or a patent under 
reexamination is rejected or objected to, any evidence submitted to 
traverse the rejection or objection on a basis not otherwise 
provided for must be by way of an oath or declaration under this 
section . 

It is the responsibility of the primary examiner to 
personally review and decide whether affidavits or declarations 
submitted under 37 CFR 1.132 for the pvirpose of traversing 
grounds of rejection are responsive to the rejection and present 
sufficient facts to overcome the rejection .' 

The contents of the previously filed affidavit were intended to provide 
testimonial evidence as to why the reference(s) do not provide/teach the subject 
matter recited in the claims. Thus, while the White Paper may have been used by 
the Examiner to reject the claims under 35 U.S.C. § 102(b), the mere fact that 35 
U.S.C. § 102(b) was used as a basis for rejection does not, prevent a proper 
affidavit under 37 CFR 1.132 (which presents evidence 'to traverse the rejection') 
fi-om being submitted and duly considered, since for example the previously filed 
affidavit provided testimonial evidence that the subject matter of the present 
claims was not present in or taught by the technology described in the White 
Paper. 

Furthermore, the Examiner misinterprets the content and intent of the 
previously filed affidavit, by interpreting the previously filed affidavit as 
attempting to prove that the subject matter of ihc Alteon and Cisco documents 
were 'derived from the inventorship of the application.' Again, it is emphasized 
herein that the previously filed affidavit was not presented to support an 
attribution/derivation argument — ^rather, the previously filed affidavit was for the 
purpose of providing testimonial evidence that the subject matter of the present 
claims was not present in or taught by the technology described in the Alteon and 
Cisco documents. 

On page 3 of the final Office Action, the Examiner alleged that 'The 
affidavit clearly admits the claims read on the White Paper.' This allegation by 
the Examiner is traversed herein — ^there is no such admission in the previously 
filed affidavit. As extensively stated and explained throughout the previously 
filed affidavit, 'the claims of the present application distinguish over the GSLB 
technology described in the White Paper.' Accordingly, the Examiner's 
allegation of said admission is clearly without merit. 

Thus, the Examiner should give the previously filed affidavit due 
consideration/reconsideration and weight. 



11 



Thus from the above, the Ms. Joshi's affidavits have provided facts and evidence 
sufficient to address or otherwise overcome the anticipation rejections based on the White Paper, 
in particular, facts/evidence that the GSLB technology of the White Paper does not teach the 
recitations of claim 34. Still fiirther, the Examiner has failed to provide counter evidence or other 
arguments to rebut the evidence provided in Ms. Joshi's affidavits that the White Paper does not 
teach the recitations of claim 34. The Examiner has not identified any teaching in the White 
Paper that overcomes or otherwise refutes Ms. Joshi's factual testimony in her affidavits of how 
the White Paper's site switch communicates with the CGS switch (and what is communicated by 
the site switch), in an architecture where a private virtual IP address is configured at the site 
switch. The facts are that the site switch of the White Paper communicates a private IP address to 
a load balancing controller, if the private VIP address is configured at the site switch. This is 
different than what is recited in claim 34. 

Accordingly, the rejection of claim 34 under 35 U.S.C. § 102(b) should be 

withdrawn. 

Even assiuning arguendo and hypothetically that Ms. Joshi's affidavits are 
unusable to address the rejections based on the White Paper and/or provide insufficient evidence 
to overcome the rejections based on the White Paper, the White Paper nevertheless does not teach 
(explicitly or inherently) the recitations of claim 34 in a manner sufficient to support an 
anticipation rejection. 

For example and as noted in page 12 of the Remarks section of the response filed 
on September 21, 2009, with regards to the recitation "obtaining at one of said site switches 
mapping information that provides a translation between a private virtual IP address, configured 
at said site switch and associated with said at least one host server corresponding to said site 
switch, and a public virtual IP address" recited in claim 34, page 4 (section 5) of the final Office 
Action of August 3, 2009 cites "a Site such as box 4 in the Figure, having a GSLB controller" of 
the White Paper. However, the final Office Action of August 3, 2009 nowhere identifies where 
the limitation "obtaining at one of said site switches mapping information that provides a 
translation..." of this recitation is specifically found/taught in the Figure and accompanying 
description of the White Paper. Indeed, as fiilly explained in the previously filed affidavits of Ms. 
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Joshi, such a feature of "obtaining ... mapping information" was not present in the GSLB 
technology that existed at the time of the White Paper. 

Further as noted in pages 12-13 of the Remarks section of the response filed on 
September 21, 2009, with regards to the recitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" page 5 (section 5) of the final Office 
Action of August 3, 2009 states that "Controller GSLB's respon[ds] with the information of the 
Hong Kong web host for load balancing... the controller... returns the address to the local DNS of 
a client in San Francisco." Such statements by the Examiner do not support the rejection. For 
instance, the recitations in claim 34 specifically state that the public virtual IP address is provided 
"to at least one load balancing controller." In contrast, the statements by the Examiner to support 
the rejection only describe an address being pro\ idcd from (rather than to) the GSLB controller 
{e.g., "Controller GSLB's respon[ds] with the infomialion of the Hong Kong web host" and "the 
controller. . .returns the address to the local DNS"). 

Still fijither and as noted in page 12 of the amendment filed on October 7, 2008 in 
response to the Office Action mailed April 11, 2008, page 5 (section 6) of the Office Action of 
April 11, 2008 has cited the Figure on page 6 of the White Paper as allegedly teaching "obtaining 
at one of said site switches mapping information that provides a translation between a private 
virtual IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address." More particularly, the Office 
Action of April 11, 2008 cited "the Figure - a Site such as a box 4 in the Figure, having a 
Controller GSLB switch that configures to associate with at least one host server: Hong Kong." 
However, the "box 4" and the accompanying description of the White Paper being relied upon by 
the Office Action of April 11, 2008 is completely silent with respect to "obtaining at one of said 
site switches mapping information that provides a translation between a private virtual IP address, 
configwed at said site switch and associated with said at least one host server corresponding to 
said site switch, and a public virtual IP address." The Examiner has failed to cite any passages of 
the White Paper where such recitations of claim 34 are taught. 

Accordingly, since the White Paper once again does not teach the recitations of 
claim 34, the rejection of claim 34 under 35 U.S.C. § 102(b) should be withdrawn. 
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2. Dependent claims 35-38 and 60 are not anticipated by the White Paper 
Rejected dependent claims 35-38 and 60 depend directly or indirectly on claim 34, 
and by virtue of this dependency, are not anticipated by the White Paper for the reasons set forth 
above with respect to claim 34. 

Furthermore, dependent claim 36 recites, inter alia, "wherein said providing, by 
said site switch, said public virtual IP address to said at least one load balancing controller further 
includes providing by said site switch said public virtual IP address to a load balancing controller 
located at said site switch " (emphasis ours). Nowhere has the Examiner identified any teaching in 
the White Paper where the site switch provides the public virtual IP address to a load balancing 
controller located at said site switch. Hence, claim 36 is allowable. 

5. Independent claim 43 is not anticipated by the White Paper 
Independent claim 43 recites, inter alia, the following (emphasis ours): 

"obtaining at said site switch mapping information that provides a 
translation between a private virtual IP address and a public virtual IP address, 
said private virtual IP address being configured at said site switch and being 
associated with at least one host server corresponding to said site switch; and 

providing, by said site switch, said public virtual IP address to at least 
one load balancing controller." 

The White Paper does not teach such recitations of claim 43. 

As previously explained above, Ms. Joshi's affidavits are usable to address the 
rejection under 35 U.S.C. § 102(b) based on the White Paper, contrary to the position taken by the 
Examiner that affidavits of any kind whatsoever cannot be used to overcome rejections under 35 
U.S.C. § 102(b). Furthermore, such affidavits by Ms. Joshi provide evidence, which the 
Examiner has not adequately refiited or otherwise successfiiUy rebutted, that the GSLB 
technology of the White Paper does not explicitly or inherently teach a "private virtual IP address 
being configured at said site switch . . . and providing, by said site switch, said public virtual IP 
address to at least one load balancing controller." 

Accordingly, the rejection of claim 34 under 35 U.S.C. § 102(b) should be 

withdrawn. 
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Even assuming arguendo and hypotheticalfy that Ms. Joshi's affidavits are 
unusable to address the rejections based on the White Paper and/or provide insufficient evidence 
to overcome the rejections based on the White Paper, the White Paper nevertheless does not teach 
(explicitly or inherently) the recitations of claim 43 in a manner sufficient to support an 
anticipation rejection. 

For example, page 6 of the final Office Action of August 3, 2009 uses the same 
rationale used to reject claim 34 in order to reject claim 43. As noted in page 12 of the Remarks 
section of the response filed on September 21, 2009, with regards to the recitation "obtaining at 
one of said site switches mapping information that provides a translation between a private virtual 
IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address" recited in claim 34, page 4 
(section 5) of the final Office Action of August 3, 2009 cites "a Site such as box 4 in the Figure, 
having a GSLB controller" of the White Paper. However, the final Office Action of August 3, 
2009 nowhere identifies where the limitation "obtaining at said site switch mapping information 
that provides a translation..." of this recitation is specifically found/taught in the Figure and 
accompanying description of the White Paper. Indeed, as fully explained in the previously filed 
affidavits of Ms. Joshi, such a feature of "obtaining ... mapping information" was not present in 
the GSLB technology that existed at the time of the White Paper. 

Further as noted in pages 12-13 of the Remarks section of the response filed on 
September 21, 2009, with regards to the recitation of "providing, by said site switch, said pubUc 
virtual IP address to at least one load balancing controller,'' page 5 (section 5) of the final Office 
Action of August 3, 2009 states that "Controller GSLB's respon[ds] with the information of the 
Hong Kong web host for load balancing... the controller... returns the address to the local DNS of 
a client in San Francisco." Such statements by the Examiner do not support the rejection. For 
instance, the recitations in claim 43 specifically state that the public virtual IP address is provided 
"/o at least one load balancing controller." In contrast, the statements by the Examiner to support 
the rejection only describe an address being provided from (rather than to) the GSLB controller 
{e.g., "Controller GSLB's respon[ds] with the information of the Hong Kong web host" and "the 
controller. . .returns the address to the local DNS"). 
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Still further and as noted in page 12 of the amendment filed on October 7, 2008 in 
response to the Office Action mailed April 11, 2008, page 5 (section 6) of the Office Action of 
April 11, 2008 has cited the Figure on Page 6 of the White Paper as allegedly teaching "obtaining 
at one of said site switches mapping information that provides a translation between a private 
virtual IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address." More particularly, the Office 
Action of April 11, 2008 cited "the Figure - a Site such as a box 4 in the Figure, having a 
Controller GSLB switch that configures to associate with at least one host server: Hong Kong." 
However, the "box 4" and the accompanying description of the White Paper being relied upon by 
the Office Action of April 11, 2008 is completely silent with respect to "obtaining at said site 
switch mapping information that provides a translation between a private virtual IP address and a 
public virtual IP address, said private virtual IP address being configured at said site switch." The 
Examiner has failed to cite any passages of the White Paper where such recitations of claim 43 
are taught. 

Accordingly, since the White Paper once again does not teach the recitations of 
claim 43, the rejection of claim 43 under 35 U.S.C. § 102(b) should be withdrawn. 

4. Dependent claims 44-46 and 61 are not anticipated by the White Paper 
Rejected dependent claims 44-46 and 61 depend directly or indirectly on claim 43, 

and by virtue of this dependency, are not anticipated by the White Paper for the reasons set forth 
above with respect to claim 43. 

Furthermore, dependent claim 45 rccilcs, inter alia, "wherein the instructions to 
provide, by said site switch, said public virtual IP address to said at least one load balancing 
controller includes instructions to provide by said site switch said public virtual IP address to a 
load balancing controller located at said site switch " (emphasis ours). Nowhere has the Examiner 
identified any teaching in the White Paper where the site switch provides the public virtual IP 
address to a load balancing controller located at said site switch. Hence, claim 45 is allowable. 

5. Independent claim 51 is not anticipated by the White Paper 

Independent claim 51 recites, inter alia, the following (emphasis ours): 
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"a site switch configurable with a private virtual IP address. . .; and 
a component in said site switch to obtain a public virtual IP address 

translated from said private virtual IP address, 

wherein said site switch is adapted to provide said obtained public virtual 

IP address to at least one load balancing controller." 

The White Paper does not teach such recitations of claim 5 1 . 

As previously explained above, Ms. Joshi's affidavits are usable to address the 
rejection under 35 U.S.C. § 102(b) based on the White Paper, contrary to the position taken by the 
Examiner that affidavits of any kind whatsoever cannot be used to overcome rejections under 35 
U.S.C. § 102(b). Furthermore, such affidavits by Ms. Joshi provide evidence, which the 
Examiner has not adequately refiited or otherwise successfully rebutted, that the GSLB 
technology of the White Paper does not explicitly or inherently teach "a site switch configurable 
with a private virtual IP address . . . and . . . said site switch is adapted to provide said obtained 
public virtual IP address to at least one load balancing controller." 

Accordingly, the rejection of claim 51 under 35 U.S.C. § 102(b) should be 

withdrawn. 

Even assuming arguendo and hypothetically that Ms. Joshi's affidavits are 
unusable to address the rejections based on the White Paper and/or provide insufficient evidence 
to overcome the rejections based on the White Paper, the White Paper nevertheless does not teach 
(explicitly or inherently) the recitations of claim 51 in a manner sufficient to support an 
anticipation rejection. 

For example, page 6 of the final Office Action of August 3, 2009 uses the same 
rationale used to reject claim 34 in order to reject claim 51. As noted in page 12 of the Remarks 
section of the response filed on September 21, 2009, with regards to the recitation "obtaining at 
one of said site switches mapping information that provides a translation between a private virtual 
IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address" recited in claim 34, page 4 
(section 5) of the final Office Action of August 3, 2009 cites "a Site such as box 4 in the Figure, 
having a GSLB controller" of the White Paper. However, the final Office Action of August 3, 
2009 nowhere identifies where the limitation "a component in said site switch to obtain a public 
virtual IP address translated from said private virtual IP address" of claim 51 is specifically 
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found/taught in the Figure and accompanying description of the White Paper. Indeed, as fully 
explained in the previously filed affidavits of Ms. Joshi, "obtaining, by the site switch, mapping 
information that provided a translation between a private virtual IP address configured at that site 
switch and a public virtual IP address" was not present in the GSLB technology that existed at the 
time of the White Paper. 

Further as noted in pages 12-13 of the Remarks section of the response filed on 
September 21, 2009, with regards to the recitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" recited in claim 34, page 5 (section 5) 
of the final Office Action of August 3, 2009 states that "Controller GSLB's respon[ds] with the 
information of the Hong Kong web host for load balancing... the controller. . .returns the address 
to the local DNS of a client in San Francisco." Such statements by the Examiner do not support 
the rejection. For instance, the recitations in claim 5 1 specifically state that the public virtual IP 
address is provided "to at least one load balancing controller." In contrast, the statements by the 
Examiner to support the rejection only describe an address being provided from (rather than to) 
the GSLB confroUer (e.g., "ConfroUer GSLB's respon[ds] with the information of the Hong Kong 
web host" and "the controller... returns the address to the local DNS"). 

Still further and as noted in page 12 of the amendment filed on October 7, 2008 in 
response to the Office Action mailed April 11, 2008, page 5 (section 6) of the Office Action of 
April 11, 2008 has cited the Figure on Page 6 of the White Paper as allegedly teaching "obtaining 
at one of said site switches mapping information that provides a franslation between a private 
virtual IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address." More particularly, the Office 
Action of April 11, 2008 cited "the Figure - a Site such as a box 4 in the Figure, having a 
Controller GSLB switch that configures to associate with at least one host server: Hong Kong." 
However, the "box 4" and the accompanying description of the White Paper being reUed upon by 
the Office Action of April 11, 2008 is completely silent with respect to "a site switch configurable 
with a private virtual IP address...; and a component in said site switch to obtain a public virtual 
IP address translated from said private virtual IP address." The Examiner has failed to cite any 
passages of the White Paper where such recitations of claim 51 are taught. 
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Accordingly, since the White Paper once again does not teach the recitations of 
claim 51, the rejection of claim 51 under 35 U.S.C. § 102(b) should be withdrawn. 

6. Dependent claims 52-55 and 62 are not anticipated by the White Paper 

Rejected dependent claims 52-55 and 62 depend directly or indirectly on claim 51, 
and by virtue of this dependency, are not anticipated by the White Paper for the reasons set forth 
above with respect to claim 51. 

Fvirthermore, dependent claim 53 recites, inter alia, "wherein said at least one load 
balancing controller includes a load balancing controller located at said site switch " (emphasis 
ours). Nowhere has the Examiner identified any teaching in the White Paper where the site 
switch provides the pubhc virtual IP address to a load balancing controller located at said site 
switch. Hence, claim 53 is allowable. 

7. Independent claim 63 is not anticipated by the White Paper 

Independent claim 63 recites, inter alia, the following (emphasis ours): 

"identifying, by a switch, a public virtual IP address that is mapped to a 
private virtual IP address configured at the switch; and 

communicating, by the switch to a load balancing controller, the 
identified public virtual IP address." 

The White Paper does not teach such recitations of claim 63. 

As previously explained above, Ms. Joshi's affidavits are usable to address the 
rejection under 35 U.S.C. § 102(b) based on the White Paper, contrary to the position taken by the 
Examiner that affidavits of any kind whatsoever cannot be used to overcome rejections under 35 
U.S.C. § 102(b). Furthermore, such affidavits by Ms. Joshi provide evidence, which the 
Examiner has not adequately refuted or otherwise successfully rebutted, that the GSLB 
technology of the White Paper does not explicitly or inherently teach "a private virtual IP address 
configured at the switch; and communicating, by the switch to a load balancing controller, the 
identified public virtual IP address." 
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Accordingly, the rejection of claim 63 under 35 U.S.C. § 102(b) should be 

withdrawn. 

Even assvuning arguendo and hypothetically that Ms. Joshi's affidavits are 
unusable to address the rejections based on the White Paper and/or provide insufficient evidence 
to overcome the rejections based on the White Paper, the White Paper nevertheless does not teach 
(explicitly or inherently) the recitations of claim 63 in a manner sufficient to support an 
anticipation rejection. 

For example, page 7 of the final Office Action of August 3, 2009 uses the same 
rationale used to reject claim 34 in order to reject claim 63. As noted in page 12 of the Remarks 
section of the response filed on September 21, 2009, with regards to the recitation "obtaining at 
one of said site switches mapping infomiation that provides a translation between a private virtual 
IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address" recited in claim 34, page 4 
(section 5) of the final Office Action of August 3, 2009 cites "a Site such as box 4 in the Figure, 
having a GSLB controller" of the White Paper. However, the final Office Action of August 3, 
2009 nowhere identifies where the limitation "identifying, by a switch, a public virtual IP address 
that is mapped to a private virtual IP address configured at the switch" of claim 63 is specifically 
found/taught in the Figure and accompanying description of the White Paper. Indeed, as fully 
explained in the previously filed affidavits of Ms. Joshi, "obtaining, by the site switch, mapping 
information that provided a translation between a private virtual IP address configured at that site 
switch and a public virtual IP address" was not present in the GSLB technology that existed at the 
time of the White Paper. 

Further as noted in pages 12-13 of the Remarks section of the response filed on 
September 21, 2009, with regards to the recitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" page 5 (section 5) of the final Office 
Action of August 3, 2009 states that "Controller GSLB's respon[ds] with the information of the 
Hong Kong web host for load balancing... the controller... returns the address to the local DNS of 
a client in San Francisco." Such statements by the Examiner do not support the rejection. For 
instance, the recitations in claim 63 specifically state that the public virtual IP address is 
communicated "to a load balancing controller." In contrast, the statements by the Examiner to 
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support the rejection only describe an address being provided from (rather than to) the GSLB 
controller (e.g., "Controller GSLB's respon[ds] with the information of the Hong Kong web host" 
and "the contt"oIIer. . .returns the address to the local DNS"). 

Still fiirther and as noted in page 12 of the Remarks section of the amendment filed 
on October 7, 2008 in response to the Office Action mailed April 11, 2008, page 5 (section 6) of 
the Office Action of April 11, 2008 has cited the Figure on Page 6 of the White Paper as allegedly 
teaching "obtaining at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated with said at 
least one host server corresponding to said site switch, and a public virtual IP address." More 
particularly, the Office Action of April 11, 2008 cited "the Figure - a Site such as a box 4 in the 
Figure, having a Controller GSLB switch that configures to associate with at least one host server: 
Hong Kong." However, the "box 4" and the accompanying description of the White Paper being 
relied upon by the Office Action of April 11, 2008 is completely silent with respect to 
"identifying, by a switch, a public virtual IP address that is mapped to a private virtual IP address 
configured at the switch." The Examiner has failed to cite any passages of the White Paper where 
such recitations of claim 63 are taught. 

Still yet further, pages 14-15 of the Remarks section of the amendment filed on 
April 23, 2009 provided the following arguments pertaining to claim 63 in response to the Office 
Action mailed December 23, 2008. Such previous arguments are being re-presented (emphasis in 
original) herein for fiuther consideration in this appeal: 

"For example, page 6 (section 4) of the present Office Action continues to 

cite and rely upon the description on page 6 and the figure on page 6 of the White 
Paper. However, the present Office Action has not cited any specific disclosure in 
the White Paper that teaches "a private virtual IP address configured at the switch" 
in the figure of page 6 and more particularly that teaches 'identify, by the switch, a 
public virtual IP address that is mapped to a private virtual IP address configured 
at the switch' as recited in claim 63. 

While page 2 (subsection entitled 'Scalability and Management') of the 
White Paper mentions that 'virtual IP (VIP) addresses are being used for server 
farms', the present Office Action has not identified any disclosure in the White 
Paper that teaches that such VIP address is private and is configured at a switch. 

Moreover, while page 3 (subsection entitled 'Security') of the White Paper 
mentions 'IP addresses made publicly available' and the need to 'hide IP 
addresses,' the present Office Action has not identified any disclosure in the White 
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Paper that teaches that such IP addresses are VIP addresses, including 'a private 
virtual IP address configured at the switch' as recited in claim 63. 

Still further, sections 8-10 of the previously filed affidavit provided 
testimonial evidence that to the extent that the technology of the White Paper 
might have involved private VIP addresses configured at a switch, the switch 
communicated the private VIP address configured thereon. This communication of 
the private VIP configured at the switch does not teach 'communicating ... the 
identified public virtual IP address' as recited in claim 63. 

It is noted that with respect to the terms 'public VIP address' and 'private 
VIP address', page 4 (section 2) of the present Office Action alleged that ' these are 
only names . It cannot cause the patentability merely based on a name, i.e. if 
granting patent protection on the disputed claim based on the name would allow 
the patentee to exclude the public from practicing the name' (emphasis ours). The 
present Office Action's allegation that the terms 'public VIP address' and 'private 
VIP address' are 'only names' is traversed herein. It is respectfully submitted that 
these terms are not merely/only 'names' but rather such terms have a plain and 
ordinary meaning that would be understood by those skilled in the art. See, e.g., 
MPEP § 21 1 1.01. It appears that by referring to these terms recited in the claims 
as being merely/only 'names', the present Office Action has not properly 
considered these terms according to their plain and ordinary meaning and therefore 
has not given these terms their due weight. Such a disposition by the present 
Office Action is contrary to MPEP § 2106, which requires that 'when evaluating 
the scope of a claim, every limitation in the claim must be considered'." 



Accordingly, since the White Paper once again does not teach the recitations of 
claim 63, the rejection of claim 63 under 35 U.S.C. § 102(b) should be withdrawn. 



8. Dependent claims 64-66 are not anticipated by the White Paper 

Rejected dependent claims 64-66 depend directly or indirectly on claim 63, and by 
virtue of this dependency, are not anticipated by the White Paper for the reasons set forth above 
with respect to claim 63. 

Furthermore, dependent claim 64 recites, inter alia, "wherein said communicating 
includes: sending, by the switch, the identified public virtual IP address to the load balancing 
controller, which is located at the switch " (emphasis ours). Nowhere has the Examiner identified 
any teaching in the White Paper where the switch communicates the public virtual IP address to a 
load balancing controller located at the switch. Hence, claim 64 is allowable. 



9. Independent claim 67 is not anticipated by the White Paper 
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Independent claim 67 recites, inter alia, the following (emphasis ours): 



"identify, by the switch, a public virtual IP address that is mapped to a 
private virtual IP address configured at the switch; and 

communicate, by the switch to a load balancing controller, the identified 
public virtual IP address." 

The White Paper does not teach such recitations of claim 67. 

As previously explained above, Ms. Joshi's affidavits are usable to address the 
rejection under 35 U.S.C. § 102(b) based on the White Paper, contrary to the position taken by the 
Examiner that affidavits of any kind whatsoever cannot be used to overcome rejections under 35 
U.S.C. § 102(b). Furthermore, such affidavits by Ms. Joshi provide evidence, which the 
Examiner has not adequately refiited or otherwise successfiilly rebutted, that the GSLB 
technology of the White Paper does not explicitly or inherently teach "a private virtual IP address 
configured at the switch; and communicate, by the switch to a load balancing controller, the 
identified public virtual IP address." 

Accordingly, the rejection of claim 67 under 35 U.S.C. § 102(b) should be 

withdrawn. 

Even assuming arguendo and hypothetically that Ms. Joshi's affidavits are 
unusable to address the rejections based on the White Paper and/or provide insufficient evidence 
to overcome the rejections based on the White Paper, the White Paper nevertheless does not teach 
(explicitly or inherently) the recitations of claim 67 in a manner sufficient to support an 
anticipation rejection. 

For example, page 7 of the final Office Action of August 3, 2009 uses the same 
rationale used to reject claim 34 in order to reject claim 67. As noted in page 12 of the Remarks 
section of the response filed on September 21, 2009, with regards to the recitation "obtaining at 
one of said site switches mapping information that provides a translation between a private virtual 
IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address" recited in claim 34, page 4 
(section 5) of the final Office Action of August 3, 2009 cites "a Site such as box 4 in the Figure, 
having a GSLB controller" of the White Paper. However, the final Office Action of August 3, 
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2009 nowhere identifies where the limitation "identify, by the switch, a public virtual IP address 
that is mapped to a private virtual IP address configured at the switch" of claim 67 is specifically 
found/taught in the Figure and accompanying description of the White Paper. Indeed, as fiilly 
explained in the previously filed affidavits of Ms. Joshi, "obtaining, by the site switch, mapping 
information that provided a translation between a private virtual IP address configured at that site 
switch and a public virtual IP address" was not present in the GSLB technology that existed at the 
time of the White Paper. 

Fvirther as noted in pages 12-13 of the Remarks section of the response filed on 
September 21, 2009, with regards to the recitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" page 5 (section 5) of the final Office 
Action of August 3, 2009 states that "Controller GSLB's respon[ds] with the information of the 
Hong Kong web host for load balancing... the controller... returns the address to the local DNS of 
a chent in San Francisco." Such statements by the Examiner do not support the rejection. For 
instance, the recitations in claim 67 specifically state that the public virtual IP address is 
communicated "to a load balancing controller." In contrast, the statements by the Examiner to 
support the rejection only describe an address being provided from (rather than to) the GSLB 
controller {e.g., "Controller GSLB's respon[ds] with the information of the Hong Kong web host" 
and "the controller. . .returns the address to the local DNS"). 

Still fiuther and as noted in page 12 of the Remarks section of the amendment filed 
on October 7, 2008 in response to the Office Action mailed April 11, 2008, page 5 (section 6) of 
the Office Action of April 11, 2008 has cited the Figure on Page 6 of the White Paper as allegedly 
teaching "obtaining at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated with said at 
least one host server corresponding to said site switch, and a public virtual IP address." More 
particularly, the Office Action of April 11, 2008 cited "the Figure - a Site such as a box 4 in the 
Figure, having a Controller GSLB switch that configures to associate with at least one host server: 
Hong Kong." However, the "box 4" and the accompanying description of the White Paper being 
relied upon by the Office Action of April 11, 2008 is completely silent with respect to "identity, 
by the switch, a public virtual IP address that is mapped to a private virtual IP address configured 
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at the switch." The Examiner has failed to cite any passages of the White Paper where such 
recitations of claim 67 are taught. 

Still yet further, pages 14-15 of the Remarks section of the amendment filed on 
April 23, 2009 provided the following arguments pertaining to claim 63 in response to the Office 
Action mailed December 23, 2008. Such previous arguments pertaining to claim 63 are 
applicable to claim 67, and are being re-presented (emphasis in original) herein for further 
consideration in this appeal: 

"For example, page 6 (section 4) of the present Office Action continues to 
cite and rely upon the description on page 6 and the figure on page 6 of the White 
Paper. However, the present Office Action has not cited any specific disclosure in 
the White Paper that teaches "a private virtual IP address configured at the switch" 
in the figure of page 6 and more particularly that teaches 'identify, by the switch, a 
public virtual IP address that is mapped to a private virtual IP address configured 
at the switch' as recited in claim 63. 

While page 2 (subsection entitled 'Scalability and Management') of the 
White Paper mentions that 'virtual IP (VIP) addresses are being used for server 
farms', the present Office Action has not identified any disclosure in the White 
Paper that teaches that such VIP address is private and is configured at a switch. 

Moreover, while page 3 (subsection entitled 'Security') of the White Paper 
mentions 'IP addresses made publicly available' and the need to 'hide IP 
addresses,' the present Office Action has not identified any disclosure in the White 
Paper that teaches that such IP addresses are VIP addresses, including 'a private 
virtual IP address configured at the switch' as recited in claim 63. 

Still further, sections 8-10 of the previously filed affidavit provided 
testimonial evidence that to the extent that the technology of the White Paper 
might have involved private VIP addresses configured at a switch, the switch 
communicated the private VIP address configured thereon. This communication of 
the private VIP configured at the switch does not teach 'communicating ... the 
identified pubhc virtual IP address' as recited in claim 63. 

It is noted that with respect to the terms 'public VIP address' and 'private 
VIP address', page 4 (section 2) of the present Office Action alleged that ' these are 
only names . It cannot cause the patentability merely based on a name, i.e. if 
granting patent protection on the disputed claim based on the name would allow 
the patentee to exclude the public from practicing the name' (emphasis ours). The 
present Office Action's allegation that the terms 'public VIP address' and 'private 
VIP address' are 'only names' is traversed herein. It is respectfiiUy submitted that 
these terms are not merely/only 'names' but rather such terms have a plain and 
ordinary meaning that would be understood by those skilled in the art. See, e.g., 
MPEP § 21 1 1 .01 . It appears that by referring to these terms recited in the claims 
as being merely/only 'names', the present Office Action has not properly 
considered these terms according to their plain and ordinary meaning and therefore 
has not given these terms their due weight. Such a disposition by the present 
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Office Action is contrary to MPEP § 2106, which requires that 'when evaluating 
the scope of a claim, every limitation in the claim must be considered'." 

Accordingly, since the White Paper once again does not teach the recitations of 
claim 67, the rejection of claim 67 vinder 35 U.S.C. § 102(b) should be withdrawn. 

10. Dependent claims 68-70 are not anticipated by the White Paper 

Rejected dependent claims 68-70 depend directly or indirectly on claim 67, and by 
virtue of this dependency, are not anticipated by the White Paper for the reasons set forth above 
with respect to claim 67. 

Furthermore, dependent claim 68 recites, inter alia, "wherein the instructions 
executable by the switch to communicate include instructions executable by the switch to: send, 
by the switch, the identified public virtual IP address to the load balancing controller, which is 
located at the switch " (emphasis ours). Nowhere has the Examiner identified any teaching in the 
White Paper where the switch communicates the public virtual IP address to a load balancing 
controller located at the switch. Hence, claim 68 is allowable. 

11. Independent claim 71 is not anticipated by the White Paper 

Independent claim 71 recites, inter alia, the following (emphasis ours): 

"the switch being adapted to identify a public virtual IP address that is 
mapped to the private virtual IP address configured at the switch, and the switch 
being adapted to communicate the identified public virtual IP address to a load 
balancing controller." 

The White Paper does not teach such recitations of claim 71. 

As previously explained above, Ms. Joshi's affidavits are usable to address the 
rejection imder 35 U.S.C. § 102(b) based on the White Paper, contrary to the position taken by the 
Examiner that affidavits of any kind whatsoever cannot be used to overcome rejections under 35 
U.S.C. § 102(b). Furthermore, such affidavits by Ms. Joshi provide evidence, which the 
Examiner has not adequately refuted or otherwise successfully rebutted, that the GSLB 
technology of the White Paper does not explicitly or inherently teach a "private virtual IP address 
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configured at the switch, and the switch being adapted to communicate the identified public 
virtual IP address to a load balancing controller." 

Accordingly, the rejection of claim 71 under 35 U.S.C. § 102(b) should be 

withdrawn. 

Even assvuning arguendo and hypothetically that Ms. Joshi's affidavits are 
unusable to address the rejections based on the White Paper and/or provide insufficient evidence 
to overcome the rejections based on the White Paper, the White Paper nevertheless does not teach 
(explicitly or inherently) the recitations of claim 71 in a manner sufficient to support an 
anticipation rejection. 

For example, page 7 of the final Office Action of August 3, 2009 uses the same 
rationale used to reject claim 34 in order to reject claim 71. As noted in page 12 of the Remarks 
section of the response filed on September 21, 2009, with regards to the recitation "obtaining at 
one of said site switches mapping information that provides a translation between a private virtual 
IP address, configured at said site switch and associated with said at least one host server 
corresponding to said site switch, and a public virtual IP address" recited in claim 34, page 4 
(section 5) of the final Office Action of August 3, 2009 cites "a Site such as box 4 in the Figure, 
having a GSLB controller" of the White Paper. However, the final Office Action of August 3, 
2009 nowhere identifies where the limitation "the switch being adapted to identify a public virtual 
IP address that is mapped to the private virtual IP address configured at the switch" of claim 71 is 
specifically found/taught in the Figure and accompanying description of the White Paper. Indeed, 
as fully explained in the previously filed affidavits of Ms. Joshi, "obtaining, by the site switch, 
mapping information that provided a translation between a private virtual IP address configured at 
that site switch and a public virtual IP address" was not present in the GSLB technology that 
existed at the time of the White Paper. 

Further as noted in pages 12-13 of the Remarks section of the response filed on 
September 21, 2009, with regards to the recitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller,'' page 5 (section 5) of the final Office 
Action of August 3, 2009 states that "Controller GSLB's respon[ds] with the information of the 
Hong Kong web host for load balancing... the controller. . .returns the address to the local DNS of 
a cUent in San Francisco." Such statements by the Examiner do not support the rejection. For 
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instance, the recitations in claim 71 specifically state that the public virtual IP address is 
communicated ''to a load balancing controller." In contrast, the statements by the Examiner to 
support the rejection only describe an address being provided from (rather than to) the GSLB 
controller (e.g., "Controller GSLB's respon[ds] with the inft)Tmation of the Hong Kong web host" 
and "the conh-oUer. . .returns the address to the local DNS"). 

Still flirther and as noted in page 12 of the Remarks section of the amendment filed 
on October 7, 2008 in response to the Office Action mailed April 11, 2008, page 5 (section 6) of 
the Office Action of April 11, 2008 has cited the Figure on Page 6 of the White Paper as allegedly 
teaching "obtaining at one of said site switches mapping information that provides a franslation 
between a private virtual IP address, configured at said site switch and associated with said at 
least one host server corresponding to said site switch, and a public virtual IP address." More 
particularly, the Office Action of April 11, 2008 cited "the Figure - a Site such as a box 4 in the 
Figure, having a Controller GSLB switch that configures to associate with at least one host server: 
Hong Kong." However, the "box 4" and the accompanying description of the White Paper being 
relied upon by the Office Action of April 11, 2008 is completely silent with respect to "identify a 
public virtual IP address that is mapped to the private virtual IP address configured at the switch." 
The Examiner has failed to cite any passages of the White Paper where such recitations of claim 
71 are taught. 

Still yet fiuther, pages 14-15 of the Remarks section of the amendment filed on 
April 23, 2009 provided the following arguments pertaining to claim 63 in response to the Office 
Action mailed December 23, 2008. Such previous arguments pertaining to claim 63 are 
applicable to claim 71, and are being re-presented (emphasis in original) herein for further 
consideration in this appeal: 

"For example, page 6 (section 4) of the present Office Action continues to 
cite and rely upon the description on page 6 and the figure on page 6 of the White 
Paper. However, the present Office Action has not cited any specific disclosure in 
the White Paper that teaches "a private virtual IP address configured at the switch" 
in the figure of page 6 and more particularly that teaches 'identify, by the switch, a 
public virtual IP address that is mapped to a private virtual IP address configured 
at the switch' as recited in claim 63. 

While page 2 (subsection entitled 'Scalability and Management') of the 
White Paper mentions that 'virtual IP (VIP) addresses are being used for server 
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farms', the present Office Action has not identified any disclosure in the White 
Paper that teaches that such VIP address is private and is configured at a switch. 

Moreover, while page 3 (subsection entitled 'Security') of the White Paper 
mentions 'IP addresses made publicly available' and the need to 'hide IP 
addresses,' the present Office Action has not identified any disclosure in the White 
Paper that teaches that such IP addresses are VIP addresses, including 'a private 
virtual IP address configured at the switch' as recited in claim 63. 

Still further, sections 8-10 of the previously filed affidavit provided 
testimonial evidence that to the extent that the technology of the White Paper 
might have involved private VIP addresses configured at a switch, the switch 
communicated the private VIP address configured thereon. This communication of 
the private VIP configured at the switch does not teach 'communicating ... the 
identified public virtual IP address' as recited in claim 63. 

It is noted that with respect to the terms 'public VIP address' and 'private 
VIP address', page 4 (section 2) of the present Office Action alleged that ' these are 
only names . It cannot cause the patentability merely based on a name, i.e. if 
granting patent protection on the disputed claim based on the name would allow 
the patentee to exclude the public from practicing the name' (emphasis ours). The 
present Office Action's allegation that the terms 'public VIP address' and 'private 
VIP address' are 'only names' is traversed herein. It is respectfiilly submitted that 
these terms are not merely/only 'names' but rather such terms have a plain and 
ordinary meaning that would be understood by those skilled in the art. See, e.g. , 
MPEP § 21 1 1.01. It appears that by referring to these terms recited in the claims 
as being merely/only 'names', the present Office Action has not properly 
considered these terms according to their plain and ordinary meaning and therefore 
has not given these terms their due weight. Such a disposition by the present 
Office Action is contrary to MPEP § 2106, which requires that 'when evaluating 
the scope of a claim, every limitation in the claim must be considered'." 



Accordingly, since the White Paper once again does not teach the recitations of 
claim 71, the rejection of claim 71 under 35 U.S. C. § 102(b) should be withdrawn. 



12. Dependent claims 72-74 are not anticipated by the White Paper 
Rejected dependent claims 72-74 depend directly or indirectly on claim 71, and by 
virtue of this dependency, are not anticipated by the White Paper for the reasons set forth above 
with respect to claim 71 . 

Furthermore, dependent claim 72 recites, inter alia, "wherein the load balancing 
controller is included in the switch " (emphasis ours). Nowhere has the Examiner identified any 
teaching in the White Paper where the switch communicates the public virtual IP address to a load 
balancing controller included in the switch. Hence, claim 72 is allowable. 



29 



B. The rejected claims are patentable under Section 103 over the Alteon 
document and the Cisco document 

Consistent with a long line of judicial holdings, MPEP § 2143.03 states that "All 
words in a claim must be considered in judging the patentability of that claim against the prior art. 
In re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970)." In order to find prima 
facie obviousness when combining references, MPEP § 2143(A)(1) states the following 
(emphasis ours): "Office personnel must articulate the following: (1) a finding that the prior art 
included each element claimed, although not necessarily in a single prior art reference, with the 
only difference between the claimed invention and the prior art being the lack of actual 
combination of the elements in a single prior art reference." MPEP § 706.02(j) further states 
(emphasis ours): "To support the conclusion that the claimed invention is directed to obvious 
subject matter, either the references must expressly or impliedly suggest the claimed invention or 
the examiner must present a convincing line of reasoning as to why the artisan would have found 
the claimed invention to have been obvious in light of the teachings of the references. Ex parte 
Clapp, 221 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)." 

The Examiner's rejection of independent claims 34, 43, 51, 63, 67, and 71 and 
their respective dependent claims as being unpatentable in view of the Alteon document and the 
Cisco document is improper. As will be explained next below, claims 34, 43, 5 1, 63, 67, and 71 
and their respective dependent claims recite elements that are not found in the Alteon document 
and the Cisco document, and as such, there is no support for the Examiner's position that the 
claims are directed to obvious subject matter. 

1. Independent claim 34 is non-obvious over the Alteon document and the 
Cisco document 

Independent claim 34 recites, inter alia, the following (emphasis ours): 

"obtaining at one of said site switches mapping information that provides 
a translation between a private virtual IP address, configured at said site switch 
and associated with said at least one host server corresponding to said site switch, 
and a public virtual IP address; and 

providing, by said site switch, said public virtual IP address to at least 
one load balancing controller." 
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Such recitations of claim 34 are not taught by the Alteon document and by the 
Cisco document, whether singly or in combination. 

Figure One on page 2 of the Alteon docviment teaches a global server load 
balancing (GSLB) system that includes web switches at sites A-C. After selecting which 
particular site A, B, or C is best suited to serve a client request, the public VIP address of the 
selected site A, B, or C is provided to the client. 

Page 9 (top paragraph) of the final Office Action of August 3, 2009 admits that the 
Alteon document does not teach a "private VIP" address configured at the site switch. To supply 
the missing teachings of the Alteon document, the Examiner relies upon the teachings on page 12 
of the Cisco document. However, the Cisco document does not cure the deficiencies of the 
Alteon document. 

Pages 12-13 of the Cisco document describe the configuration to use a content 
services switch (CSS) to perform network address translation (NAT) to translate a private IP 
address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address (e.g., the 
public VIP address 192.200.200.200) and vice versa. However, the Examiner has failed to show 
where the Cisco document teaches that the private IP address 10.0.3.251 is a virtual IP (VIP) 
address. Instead, it has been argued against the Examiner throughout prosecution that (1) the 
Alteon document does not teach a private virtual IP (VIP) address configured at a site switch, and 
(2) the Cisco document does not teach that it's private IP address 10.0.3.251 is a private virtual IP 
(VIP) address. 

For example, pages 12-13 of the Remarks section of the amendment filed on April 
23, 2009 (in response to the Office Action mailed December 23, 2008) provided arguments 
against the Examiner as to why the recitations of claim 34 were not taught by the Alteon 
document and the Cisco document. Such arguments are being re-presented below (emphasis 
added) in this Appellant's Brief for fUrther consideration: 

". . .Figure One and the accompanying description on page 2 of the Alteon 
document describe site switch A that 'returns site B's virtual IP address (VIP) 
address [172.176.110.20] to the client's local DNS.' The local DNS server then 
'responds to client with site B's VIP' and the client 'opens application session to 
IP 172.176.110.20.' Since the VIP address 172.176.110.20 is returned to the 
client and the client is able to open a session to this VIP address, this means that 
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the VIP address 172.176.110.20 is a public VIP address configured at site B 
(described in the Alteon document as 'site B's virtual IP address'). Thus, the 
Alteon document does not describe an implementation involving private VIP 
address configured at the site switch, and therefore it is respectfiiUy submitted that 
the Alteon document does not provide the features in claim [34] of (a) 'obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address,' and (b) 'providing, by said site switch, said public virtual IP 
address to at least one load balancing controller.' 

Pages 12-13 of the Cisco document describe the configuration to use a 
content services switch (CSS) to perform network address translation (NAT) to 
translate a private IP address of a server (e.g., the private IP address 10.0.3.251) to 
a public VIP address (e.g., the public VIP address 192.200.200.200) and vice 
versa. According to Ms. Joshi's reading of the Cisco document, the private IP 
address 10.0.3.251 of the server described in the Cisco document is a private real 
IP address of the server, rather than a private virtual IP address that is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP 
address of a server, rather than a private VIP address configured at a site switch, 
is provided on page 12 of the Cisco document, which states that "The source 
group enables the CSS to perform Network Address Translation to translate 
outbound traffic source IP addresses from the server's private IP address 
(10.0.3.251) to the public VIP address (192.200.200.200). To prevent server 
source port collisions, the CSS performs Network Address Translation on the 
server's source IP address and port by translating the: Source IP address to the IP 
address defined in the source group" (emphasis added). Accordingly, the Cisco 
document also does not provide the claimed features in claim 34 of (a) "obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address," and (b) "providing, by said site switch, said public virtual IP 
address to at least one load balancing controller." 



Thus, fi-om the above arguments, the Alteon document does not teach a private 
VIP address configured at a site switch, and instead teaches a public VIP address configured at a 
site and provided to a client device (rather than to a load balancing controller). With respect to 
the Cisco document, the private IP address 10.0.3.251 of the server taught in the Cisco document 
appears to be a private real address, rather than a private virtual (VIP) address as required by 
claim 34. Fiarthermore, the private IP address 10.0.3.251 of the Cisco document is configured at a 
server, rather than being configured at a switch as required by claim 34. 
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Pages 13-14 of the Remarks section of the response filed on September 21, 2009 
(in response to the final Office Action of August 3, 2009) provided still further arguments against 
the Examiner as to why the recitations of claim 34 were not taught by the Alteon document and 
the Cisco document. Such arguments are being re-presented below (emphasis added) in this 
Appellant's Brief for further consideration 

"As clearly taught by the Alteon document on page 2 (Figure One), site 
B's virtual IP address is returned "to the cHent's local DNS" at "3". Thus, since 
the Alteon document teaches returning the virtual IP address to the client's local 
DNS, rather than to at least one load balancing controller, the Alteon document 
does not meet at least the limitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" in claim 34. 

Furthermore, while page 8 (section 7) of the Alteon document mentions 
DSSP (a.k.a. distributed site state protocol, which the Examiner appears to be 
interpreting as some sort of load balancing process), the Alteon document clearly 
teaches on pages 4-5 that DSSP is used by the "DNS authoritative name server" 
and mentions nothing about DSSP being implemented/used by the client's local 
DNS. The "DNS authoritative name server" is clearly not the same as the 
"client's local DNS" that receives site B's virtual IP address at "3." Furthermore, 
a local DNS inherently does not perform load balancing since such a local DNS 
only operates to resolve a domain name for its a local chent. Accordingly, it is 
not accurate to interpret the "client's local DNS" as being the same as the "load 
balancing controller" recited in claim 34. 

With regards to the Cisco document, this document was merely cited for 
allegedly teaching translation between public and private virtual IP addresses. 
The Cisco docviment is no more relevant than the Alteon document — both 
documents do not teach the features recited in claim 34." 



Still fiirther, sections 13-14 of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides testimonial evidence as to why a person having knowledge of those skilled 
in the art would believe that the Alteon document and the Cisco document do not teach 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address; and providing, by said 
site switch, said public virtual IP address to at least one load balancing controller." 

Hence, the Alteon document and the Cisco document, whether singly or in 
combination, do not teach the recitations of "obtaining at one of said site switches mapping 
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information that provides a translation between a private virtual IP address, configured at said site 
switch. . ., and a public virtual IP address; and providing, by said site switch, said public virtual IP 
address to at least one load balancing controller" in claim 34. Accordingly, the Examiner's 
rejection of claim 34 should be withdrawn, since the requirements of MPEP § 706.02(j) have not 
been met: "To support the conclusion that the claimed invention is directed to obvious subject 
matter, either the references must expressly or impliedly suggest the claimed invention or the 
examiner must present a convincing line of reasoning as to why the artisan would have found the 
claimed invention to have been obvious in light of the teachings of the references. Ex parte 
Clapp, 221 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)" (emphasis ours). 

2. Dependent claims 35-38 and 60 are non-obvious over the Alteon 
document and the Cisco document 

Rejected dependent claims 35-38 and 60 depend directly or indirectly on claim 34, 
and by virtue of this dependency, are non-obvious over the Alteon document and the Cisco 
document for the reasons set forth above with respect to claim 34. 

Furthermore, dependent claim 36 recites, inter alia, "wherein said providing, by 
said site switch, said public virtual IP address to said at least one load balancing controller further 
includes providing by said site switch said public virtual IP address to a load balancing controller 
located at said site switch " (emphasis ours). Nowhere has the Examiner identified any teaching in 
the Alteon docviment and the Cisco document where the site switch provides the public virtual IP 
address to a load balancing controller located at said site switch. Hence, claim 36 is allowable. 

3. Independent claim 43 is non-obvious over the Alteon document and the 
Cisco document 

Independent claim 43 recites, inter alia, the following (emphasis ours): 

"obtaining at said site switch mapping information that provides a 
translation between a private virtual IP address and a public virtual IP address, 
said private virtual IP address being configured at said site switch and being 
associated with at least one host server corresponding to said site switch; and 

providing, by said site switch, said public virtual IP address to at least 
one load balancing controller.'' 
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Such recitations of claim 43 are not taught by the Alteon dociiment and by the 
Cisco document, whether singly or in combination. 

Figure One on page 2 of the Alteon docviment teaches a global server load 
balancing (GSLB) system that includes web switches at sites A-C. After selecting which 
particular site A, B, or C is best suited to serve a client request, the public VIP address of the 
selected site A, B, or C is provided to the client. 

Page 9 (top paragraph) of the final Office Action of August 3, 2009 admits that the 
Alteon document does not teach a "private VIP" address configured at the site switch. To supply 
the missing teachings of the Alteon document, the Examiner relies upon the teachings on page 12 
of the Cisco document. However, the Cisco document does not cure the deficiencies of the 
Alteon document. 

Pages 12-13 of the Cisco document describe the configuration to use a content 
services switch (CSS) to perform network address translation (NAT) to translate a private IP 
address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address (e.g., the 
public VIP address 192.200.200.200) and vice versa. However, the Examiner has failed to show 
where the Cisco document teaches that the private IP address 10.0.3.251 is a virtual IP (VIP) 
address. Instead, it has been argued against the Examiner throughout prosecution that (1) the 
Alteon document does not teach a private virtual IP (VIP) address configured at a site switch, and 
(2) the Cisco document does not teach that it's private IP address 10.0.3.251 is a private virtual IP 
(VIP) address. 

Page 1 1 of the final Office Action of August 3, 2009 uses the same rationale used 
to reject claim 34 in order to reject claim 43. Pages 12-13 of the Remarks section of the 
amendment filed on April 23, 2009 (in response to the Office Action mailed December 23, 2008) 
provided arguments against the Examiner as to why the recitations of claim 34 were not taught by 
the Alteon docviment and the Cisco document. Such arguments are appUcable to claim 43 and are 
being re-presented below (emphasis added) in this Appellant's Brief for further consideration: 

"...Figure One and the accompanying description on page 2 of the Alteon 
document describe site switch A that 'returns site B's virtual IP address (VIP) 
address [172.176.110.20] to the client's local DNS.' The local DNS server then 
'responds to client with site B's VIP' and the client 'opens application session to 
IP 172.176.110.20.' Since the VIP address 172.176.110.20 is returned to the 
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client and the client is able to open a session to this VIP address, this means that 
the VIP address 172.176.110.20 is a public VIP address configured at site B 
(described in the Alteon document as 'site B's virtual IP address'). Thus, the 
Alteon document does not describe an implementation involving private VIP 
address configured at the site switch, and therefore it is respectfiiUy submitted that 
the Alteon document does not provide the features in claim [34] of (a) 'obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address,' and (b) 'providing, by said site switch, said public virtual IP 
address to at least one load balancing controller.' 

Pages 12-13 of the Cisco document describe the configuration to use a 
content services switch (CSS) to perform network address translation (NAT) to 
translate a private IP address of a server (e.g., the private IP address 10.0.3.251) to 
a public VIP address (e.g., the public VIP address 192.200.200.200) and vice 
versa. According to Ms. Joshi's reading of the Cisco document, the private IP 
address 10.0.3.251 of the ser\'er described in the Cisco document is a private real 
IP address of the server, rather than a private virtual IP address that is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP 
address of a server, rather than a private VIP address configured at a site switch, 
is provided on page 12 of the Cisco document, which states that "The source 
group enables the CSS to perform Network Address Translation to translate 
outbound traffic source IP addresses from the server's private IP address 
(10.0.3.251) to the public VIP address (192.200.200.200). To prevent server 
source port collisions, the CSS performs Network Address Translation on the 
server's source IP address and port by translating the: Source IP address to the IP 
address defined in the source group" (emphasis added). Accordingly, the Cisco 
document also does not provide the claimed features in claim 34 of (a) "obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address," and (b) "providing, by said site switch, said public virtual IP 
address to at least one load balancing controller." 



Thus, from the above arguments, the Alteon document does not teach a private 
VIP address configured at a site switch, and instead teaches a public VIP address configured at a 
site and provided to a client device (rather than to a load balancing controller). With respect to 
the Cisco document, the private IP address 10.0.3.251 of the server taught in the Cisco document 
appears to be a private real address, rather than a private virtual (VIP) address as required by 
claim 43. Furthermore, the private IP address 10.0.3.251 of the Cisco document is configured at a 
server, rather than being configured at a switch as required by claim 43. 



36 



Pages 13-14 of the Remarks section of the response filed on September 21, 2009 
(in response to the final Office Action of August 3, 2009) provided still fiirther arguments against 
the Examiner as to why the recitations of claim 34 were not taught by the Alteon document and 
the Cisco document. Such arguments are also applicable to claim 43 and are being re-presented 
below (emphasis added) in this Appellant's Brief for further consideration 

"As clearly taught by the Alteon document on page 2 (Figure One), site 
B's virtual IP address is returned "to the cHent's local DNS" at "3". Thus, since 
the Alteon document teaches returning the virtual IP address to the client's local 
DNS, rather than to at least one load balancing controller, the Alteon document 
does not meet at least the limitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" in claim 34. 

Furthermore, while page 8 (section 7) of the Alteon document mentions 
DSSP (a.k.a. distributed site state protocol, which the Examiner appears to be 
interpreting as some sort of load balancing process), the Alteon document clearly 
teaches on pages 4-5 that DSSP is used by the "DNS authoritative name server" 
and mentions nothing about DSSP being implemented/used by the client's local 
DNS. The "DNS authoritative name server" is clearly not the same as the 
"client's local DNS" that receives site B's virtual IP address at "3." Furthermore, 
a local DNS inherently does not perform load balancing since such a local DNS 
only operates to resolve a domain name for its a local cUent. Accordingly, it is 
not accurate to interpret the "client's local DNS" as being the same as the "load 
balancing controller" recited in claim 34. 

With regards to the Cisco document, this document was merely cited for 
allegedly teaching translation between public and private virtual IP addresses. 
The Cisco document is no more relevant than the Alteon document — both 
documents do not teach the features recited in claim 34." 



Still fiirther, sections 13-14 of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides testimonial evidence as to why a person having knowledge of those skilled 
in the art would believe that the Alteon document and the Cisco document do not teach 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address; and providing, by said 
site switch, said public virtual IP address to at least one load balancing controller." 

Hence, the Alteon document and the Cisco document, whether singly or in 
combination, do not teach the recitations of "obtaining at said site switch mapping information 
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that provides a translation between a private virtual IP address and a public virtual IP address, 
said private virtual IP address being configured at said site switch. . . ; and providing, by said site 
switch, said public virtual IP address to at least one load balancing controller" in claim 43. 
Accordingly, the Examiner's rejection of claim 43 should be withdrawn, since the requirements of 
MPEP § 706.02(j) have not been met: "To support the conclusion that the claimed invention is 
directed to obvious subject matter, either the references must expressly or impliedly suggest the 
claimed invention or the examiner must present a convincing line of reasoning as to why the 
artisan would have found the claimed invention to have been obvious in light of the teachings of 
the references. Ex parte Clapp, 111 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)" (emphasis 
ours). 

4. Dependent claims 44-46 and 61 are non-obvious over the Alteon 
document and the Cisco document 

Rejected dependent claims 44-46 and 61 depend directly or indirectly on claim 43, 
and by virtue of this dependency, are non-obvious over the Alteon document and the Cisco 
document for the reasons set forth above with respect to claim 43. 

Furthermore, dependent claim 45 recites, inter alia, "wherein the instructions to 
provide, by said site switch, said public virtual IP address to said at least one load balancing 
controller includes instructions to provide by said site switch said pubhc virtual IP address to a 
load balancing controller located at said site switch " (emphasis ours). Nowhere has the Examiner 
identified any teaching in the Alteon document or the Cisco document where the site switch 
provides the public virtual IP address to a load balancing controller located at said site switch. 
Hence, claim 45 is allowable 

5. Independent claim 51 is non-obvious over the Alteon document and the 
Cisco document 

Independent claim 51 recites, inter alia, the following (emphasis ours): 

"a site switch configurable with a private virtual IP address. ..; and 
a component in said site switch to obtain a public virtual IP address 
translated from said private virtual IP address. 
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wherein said site switch is adapted to provide said obtained public virtual 
IP address to at least one load balancing controller r 



Such recitations of claim 5 1 are not taught by the Alteon document and by the 
Cisco document, whether singly or in combination. 

Figure One on page 2 of the Alteon document teaches a global server load 
balancing (GSLB) system that includes web switches at sites A-C. After selecting which 
particular site A, B, or C is best suited to serve a client request, the public VIP address of the 
selected site A, B, or C is provided to the client. 

Page 9 (top paragraph) of the final Office Action of August 3, 2009 admits that the 
Alteon document does not teach a "private VIP" address configured at the site switch. To supply 
the missing teachings of the Alteon document, the Examiner relies upon the teachings on page 12 
of the Cisco document. However, the Cisco document does not cure the deficiencies of the 
Alteon document. 

Pages 12-13 of the Cisco document describe the configuration to use a content 
services switch (CSS) to perform network address translation (NAT) to translate a private IP 
address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address {e.g., the 
public VIP address 192.200.200.200) and vice versa. However, the Examiner has failed to show 
where the Cisco docviment teaches that the private IP address 10.0.3.251 is a virtual IP (VIP) 
address. Instead, it has been argued against the Examiner throughout prosecution that (1) the 
Alteon document does not teach a private virtual IP (VIP) address configured at a site switch, and 
(2) the Cisco document does not teach that it's private IP address 10.0.3.251 is a private virtual IP 
(VIP) address. 

Page 1 1 of the final Office Action of August 3, 2009 uses the same rationale used 
to reject claim 34 in order to reject claim 51. Pages 12-13 of the Remarks section of the 
amendment filed on April 23, 2009 (in response to the Office Action mailed December 23, 2008) 
provided arguments against the Examiner as to why the recitations of claim 34 were not taught by 
the Alteon document and the Cisco document. Such arguments are applicable to claim 5 1 and are 
being re-presented below (emphasis added) in this Appellant's Brief for fijrther consideration: 
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"...Figure One and the accompanying description on page 2 of the Aheon 
document describe site switch A that 'returns site B's virtual IP address (VIP) 
address [172.176.110.20] to the client's local DNS.' The local DNS server then 
'responds to chent with site B's VIP' and the client 'opens application session to 
IP 172.176.110.20.' Since the VIP address 172.176.110.20 is returned to the 
client and the client is able to open a session to this VIP address, this means that 
the VIP address 172.176.110.20 is a public VIP address configured at site B 
(described in the Alteon document as 'site B's virtual IP address'). Thus, the 
Alteon document does not describe an implementation involving private VIP 
address configured at the site switch, and therefore it is respectfiiUy submitted that 
the Alteon document does not provide the features in claim [34] of (a) 'obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address,' and (b) 'providing, by said site switch, said public virtual IP 
address to at least one load balancing controller.' 

Pages 12-13 of the Cisco document describe the configuration to use a 
content services switch (CSS) to perform network address translation (NAT) to 
translate a private IP address of a server (e.g., the private IP address 10.0.3.251) to 
a public VIP address (e.g., the public VIP address 192.200.200.200) and vice 
versa. According to Ms. Joshi's reading of the Cisco document, the private IP 
address 10.0.3.251 of the server described in the Cisco document is a private real 
IP address of the server, rather than a private virtual IP address that is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP 
address of a server, rather than a private VIP address configured at a site switch, 
is provided on page 12 of the Cisco document, which states that "The source 
group enables the CSS to perform Network Address Translation to translate 
outbound traffic source IP addresses from the server's private IP address 
(10.0.3.251) to the pubhc VIP address (192.200.200.200). To prevent server 
source port collisions, the CSS performs Network Address Translation on the 
server's source IP address and port by translating the: Source IP address to the IP 
address defined in the source group" (emphasis added). Accordingly, the Cisco 
document also does not provide the claimed features in claim 34 of (a) "obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address," and (b) "providing, by said site switch, said public virtual IP 
address to at least one load balancing controller." 



Thus, from the above arguments, the Alteon document does not teach a private 
VIP address configured at a site switch, and instead teaches a public VIP address configured at a 
site and provided to a cUent device (rather than to a load balancing controller). With respect to 
the Cisco document, the private IP address 10.0.3.251 of the server taught in the Cisco document 
appears to be a private real address, rather than a private virtual (VIP) address as required by 
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claim 51. Furthermore, the private IP address 10.0.3.251 of the Cisco document is configured at a 
server, rather than being configured at a switch as required by claim 51. 

Pages 13-14 of the Remarks section of the response filed on September 21, 2009 
(in response to the final Office Action of August 3, 2009) provided still further arguments against 
the Examiner as to v^^hy the recitations of claim 34 were not taught by the Alteon document and 
the Cisco document. Such arguments are also applicable to claim 5 1 and are being re-presented 
below (emphasis added) in this Appellant's Brief for further consideration 

"As clearly taught by the Alteon document on page 2 (Figure One), site 
B's virtual IP address is returned "to the cUent's local DNS" at "3". Thus, since 
the Alteon document teaches returning the virtual IP address to the client's local 
DNS, rather than to at least one load balancing controller, the Alteon document 
does not meet at least the limitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" in claim 34. 

Furthermore, while page 8 (section 7) of the Alteon document mentions 
DSSP (a.k.a. distributed site state protocol, which the Examiner appears to be 
interpreting as some sort of load balancing process), the Alteon document clearly 
teaches on pages 4-5 that DSSP is used by the "DNS authoritative name server" 
and mentions nothing about DSSP being implemented/used by the client's local 
DNS. The "DNS authoritative name server" is clearly not the same as the 
"client's local DNS" that receives site B's virtual IP address at "3." Furthermore, 
a local DNS inherently does not perform load balancing since such a local DNS 
only operates to resolve a domain name for its a local cUent. Accordingly, it is 
not accurate to interpret the "client's local DNS" as being the same as the "load 
balancing controller" recited in claim 34. 

With regards to the Cisco document, this document was merely cited for 
allegedly teaching translation between pubUc and private virtual IP addresses. 
The Cisco document is no more relevant than the Alteon docviment — both 
documents do not teach the features recited in claim 34." 



Still fiirther, sections 13-14 of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides testimonial evidence as to why a person having knowledge of those skilled 
in the art would believe that the Alteon document and the Cisco document do not teach 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address; and providing, by said 
site switch, said public virtual IP address to at least one load balancing controller." 
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Hence, the Alteon document and the Cisco document, whether singly or in 
combination, do not teach the recitations of "a site switch configurable with a private virtual IP 
address...; and a component in said site switch to obtain a public virtual IP address translated 
from said private virtual IP address, wherein said site switch is adapted to provide said obtained 
public virtual IP address to at least one load balancing confroUer" in claim 51. Accordingly, the 
Examiner's rejection of claim 51 should be withdrawn, since the requirements of MPEP 
§ 706.02(j) have not been met: "To support the conclusion that the claimed invention is directed 
to obvious subject matter, either the references must expressly or impliedly suggest the claimed 
invention or the examiner must present a convincing line of reasoning as to why the artisan would 
have found the claimed invention to have been obvious in light of the teachings of the references. 
Ex parte Clapp, 111 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)" (emphasis ours). 

6. Dependent claims 52-55 and 62 are non-obvious over the Alteon 
document and the Cisco document 

Rejected dependent claims 52-55 and 62 depend directly or indirectly on claim 51, 

and by virtue of this dependency, are non-obvious over the Alteon document and the Cisco 
document for the reasons set forth above with respect to claim 5 1 . 

Furthermore, dependent claim 53 recites, inter alia, "wherein said at least one load 
balancing confroUer includes a load balancing confroUer located at said site switch " (emphasis 
ours). Nowhere has the Examiner identified any teaching in the Alteon document or the Cisco 
document where the site switch provides the public virtual IP address to a load balancing 
controller located at said site switch. Hence, claim 53 is allowable. 

7. Independent claim 63 is non-obvious over the Alteon document and the 
Cisco document 

Independent claim 63 recites, inter alia, the following (emphasis ours): 

"identifying, by a switch, a public virtual IP address that is mapped to a 
private virtual IP address configured at the switch; and 

communicating, by the switch to a load balancing controller, the 
identified public virtual IP address." 



42 



Such recitations of claim 63 are not taught by the Alteon dociiment and by the 
Cisco document, whether singly or in combination. 

Figure One on page 2 of the Alteon docviment teaches a global server load 
balancing (GSLB) system that includes web switches at sites A-C. After selecting which 
particular site A, B, or C is best suited to serve a client request, the public VIP address of the 
selected site A, B, or C is provided to the client. 

Page 9 (top paragraph) of the final Office Action of August 3, 2009 admits that the 
Alteon document does not teach a "private VIP" address configured at the site switch. To supply 
the missing teachings of the Alteon document, the Examiner relies upon the teachings on page 12 
of the Cisco document. However, the Cisco document does not cure the deficiencies of the 
Alteon document. 

Pages 12-13 of the Cisco document describe the configuration to use a content 
services switch (CSS) to perform network address translation (NAT) to translate a private IP 
address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address (e.g., the 
public VIP address 192.200.200.200) and vice versa. However, the Examiner has failed to show 
where the Cisco document teaches that the private IP address 10.0.3.251 is a virtual IP (VIP) 
address. Instead, it has been argued against the Examiner throughout prosecution that (1) the 
Alteon document does not teach a private virtual IP (VIP) address configured at a switch, and (2) 
the Cisco docviment does not teach that it's private IP address 10.0.3.251 is a private virtual IP 
(VIP) address. 

Page 1 1 of the final Office Action of August 3, 2009 uses the same rationale used 
to reject claim 34 in order to reject claim 63. Pages 12-13 of the Remarks section of the 
amendment filed on April 23, 2009 (in response to the Office Action mailed December 23, 2008) 
provided arguments against the Examiner as to why the recitations of claim 34 were not taught by 
the Alteon docviment and the Cisco docviment. Such arguments are applicable to claim 63 and are 
being re-presented below (emphasis added) in this Appellant's Brief for fUrther consideration: 

"...Figure One and the accompanying description on page 2 of the Alteon 
document describe site switch A that 'returns site B's virtual IP address (VIP) 
address [172.176.110.20] to the client's local DNS.' The local DNS server then 
'responds to client with site B's VIP' and the client 'opens application session to 
IP 172.176.110.20.' Since the VIP address 172.176.110.20 is returned to the 
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client and the client is able to open a session to this VIP address, this means that 
the VIP address 172.176.110.20 is a public VIP address configured at site B 
(described in the Alteon document as 'site B's virtual IP address'). Thus, the 
Alteon document does not describe an implementation involving private VIP 
address configured at the site switch, and therefore it is respectfiiUy submitted that 
the Alteon document does not provide the features in claim [34] of (a) 'obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address,' and (b) 'providing, by said site switch, said public virtual IP 
address to at least one load balancing controller.' 

Pages 12-13 of the Cisco document describe the configuration to use a 
content services switch (CSS) to perform network address translation (NAT) to 
translate a private IP address of a server (e.g., the private IP address 10.0.3.251) to 
a public VIP address (e.g., the public VIP address 192.200.200.200) and vice 
versa. According to Ms. Joshi's reading of the Cisco document, the private IP 
address 10.0.3.251 of the server described in the Cisco document is a private real 
IP address of the server, rather than a private virtual IP address that is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP 
address of a server, rather than a private VIP address configured at a site switch, 
is provided on page 12 of the Cisco document, which states that "The source 
group enables the CSS to perform Network Address Translation to translate 
outbound traffic source IP addresses from the server's private IP address 
(10.0.3.251) to the pubUc VIP address (192.200.200.200). To prevent server 
source port collisions, the CSS performs Network Address Translation on the 
server's source IP address and port by translating the: Source IP address to the IP 
address defined in the source group" (emphasis added). Accordingly, the Cisco 
document also does not provide the claimed features in claim 34 of (a) "obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address," and (b) "providing, by said site switch, said public virtual IP 
address to at least one load balancing controller." 



Thus, fi-om the above arguments, the Alteon document does not teach a private 
VIP address configured at a switch, and instead teaches a public VIP address configured at a site 
and provided to a client device (rather than to a load balancing controller). With respect to the 
Cisco document, the private IP address 10.0.3.251 of the server taught in the Cisco document 
appears to be a private real address, rather than a private virtual (VIP) address as required by 
claim 63. Furthermore, the private IP address 10.0.3.251 of the Cisco document is configured at a 
server, rather than being configured at a switch as required by claim 63. 
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Pages 13-14 of the Remarks section of the response filed on September 21, 2009 
(in response to the fmal Office Action of August 3, 2009) provided still further arguments against 
the Examiner as to why the recitations of claim 34 were not taught by the Alteon document and 
the Cisco document. Such arguments are also applicable to claim 63 and are being re-presented 
below (emphasis added) in this Appellant's Brief for further consideration 

"As clearly taught by the Alteon document on page 2 (Figure One), site 
B's virtual IP address is returned "to the cHent's local DNS" at "3". Thus, since 
the Alteon document teaches returning the virtual IP address to the client's local 
DNS, rather than to at least one load balancing controller, the Alteon document 
does not meet at least the limitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" in claim 34. 

Furthermore, while page 8 (section 7) of the Alteon document mentions 
DSSP (a.k.a. distributed site state protocol, which the Examiner appears to be 
interpreting as some sort of load balancing process), the Alteon document clearly 
teaches on pages 4-5 that DSSP is used by the "DNS authoritative name server" 
and mentions nothing about DSSP being implemented/used by the client's local 
DNS. The "DNS authoritative name server" is clearly not the same as the 
"client's local DNS" that receives site B's virtual IP address at "3." Furthermore, 
a local DNS inherently does not perform load balancing since such a local DNS 
only operates to resolve a domain name for its a local chent. Accordingly, it is 
not accurate to interpret the "client's local DNS" as being the same as the "load 
balancing controller" recited in claim 34. 

With regards to the Cisco document, this document was merely cited for 
allegedly teaching translation between public and private virtual IP addresses. 
The Cisco document is no more relevant than the Alteon document — both 
documents do not teach the features recited in claim 34." 



Still fiirther, sections 13-14 of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides testimonial evidence as to why a person having knowledge of those skilled 
in the art would believe that the Alteon document and the Cisco document do not teach 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address; and providing, by said 
site switch, said public virtual IP address to at least one load balancing controller." 

Hence, the Alteon document and the Cisco document, whether singly or in 
combination, do not teach the recitations of "identifying, by a switch, a public virtual IP address 
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that is mapped to a private virtual IP address configured at the switch; and communicating, by the 
switch to a load balancing controller, the identified public virtual IP address" in claim 63. 
Accordingly, the Examiner's rejection of claim 63 should be withdrawn, since the requirements of 
MPEP § 706.02(j) have not been met: "To support the conclusion that the claimed invention is 
directed to obvious subject matter, either the references must expressly or impliedly suggest the 
claimed invention or the examiner must present a convincing line of reasoning as to why the 
artisan would have found the claimed invention to have been obvious in light of the teachings of 
the references. Ex parte Clapp, 111 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)" (emphasis 
ours). 

8. Dependent claims 64-66 are non-obvious over the Alteon document and 

the Cisco document 

Rejected dependent claims 64-66 depend directly or indirectly on claim 63, and by 
virtue of this dependency, are non-obvious over the Alteon document and the Cisco docviment for 
the reasons set forth above with respect to claim 63. 

Furthermore, dependent claim 64 recites, inter alia, "wherein said communicating 
includes: sending, by the switch, the identified public virtual IP address to the load balancing 
controller, which is located at the switch " (emphasis ours). Nowhere has the Examiner identified 
any teaching in the Alteon document or the Cisco document where the switch communicates the 
pubhc virtual IP address to a load balancing controller located at the switch. Hence, claim 64 is 
allowable. 

9. Independent claim 67 is non-obvious over the Alteon document and the 
Cisco document 

Independent claim 67 recites, inter alia, the following (emphasis ours): 

"identify, by the switch, a public virtual IP address that is mapped to a 
private virtual IP address configured at the switch; and 

communicate, by the switch to a load balancing controller, the identified 
public virtual IP address." 
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Such recitations of claim 67 are not taught by the Alteon dociiment and by the 
Cisco document, whether singly or in combination. 

Figure One on page 2 of the Alteon docviment teaches a global server load 
balancing (GSLB) system that includes web switches at sites A-C. After selecting which 
particular site A, B, or C is best suited to serve a client request, the public VIP address of the 
selected site A, B, or C is provided to the client. 

Page 9 (top paragraph) of the final Office Action of August 3, 2009 admits that the 
Alteon document does not teach a "private VIP" address configured at the site switch. To supply 
the missing teachings of the Alteon document, the Examiner relies upon the teachings on page 12 
of the Cisco document. However, the Cisco document does not cure the deficiencies of the 
Alteon document. 

Pages 12-13 of the Cisco document describe the configuration to use a content 
services switch (CSS) to perform network address translation (NAT) to translate a private IP 
address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address (e.g., the 
public VIP address 192.200.200.200) and vice versa. However, the Examiner has failed to show 
where the Cisco document teaches that the private IP address 10.0.3.251 is a virtual IP (VIP) 
address. Instead, it has been argued against the Examiner throughout prosecution that (1) the 
Alteon document does not teach a private virtual IP (VIP) address configured at a switch, and (2) 
the Cisco document does not teach that it's private IP address 10.0.3.251 is a private virtual IP 
(VIP) address. 

Page 1 1 of the final Office Action of August 3, 2009 uses the same rationale used 
to reject claim 34 in order to reject claim 67. Pages 12-13 of the Remarks section of the 
amendment filed on April 23, 2009 (in response to the Office Action mailed December 23, 2008) 
provided arguments against the Examiner as to why the recitations of claim 34 were not taught by 
the Alteon docviment and the Cisco document. Such arguments are appUcable to claim 67 and are 
being re-presented below (emphasis added) in this Appellant's Brief for further consideration: 

"...Figure One and the accompanying description on page 2 of the Alteon 
document describe site switch A that 'returns site B's virtual IP address (VIP) 
address [172.176.110.20] to the client's local DNS.' The local DNS server then 
'responds to client with site B's VIP' and the client 'opens application session to 
IP 172.176.110.20.' Since the VIP address 172.176.110.20 is returned to the 
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client and the client is able to open a session to this VIP address, this means that 
the VIP address 172.176.110.20 is a public VIP address configured at site B 
(described in the Alteon document as 'site B's virtual IP address'). Thus, the 
Alteon document does not describe an implementation involving private VIP 
address configured at the site switch, and therefore it is respectfiiUy submitted that 
the Alteon document does not provide the features in claim [34] of (a) 'obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address,' and (b) 'providing, by said site switch, said public virtual IP 
address to at least one load balancing controller.' 

Pages 12-13 of the Cisco document describe the configuration to use a 
content services switch (CSS) to perform network address translation (NAT) to 
translate a private IP address of a server (e.g., the private IP address 10.0.3.251) to 
a public VIP address (e.g., the public VIP address 192.200.200.200) and vice 
versa. According to Ms. Joshi's reading of the Cisco document, the private IP 
address 10.0.3.251 of the server described in the Cisco document is a private real 
IP address of the server, rather than a private virtual IP address that is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP 
address of a server, rather than a private VIP address configured at a site switch, 
is provided on page 12 of the Cisco document, which states that "The source 
group enables the CSS to perform Network Address Translation to translate 
outbound traffic source IP addresses from the server's private IP address 
(10.0.3.251) to the pubUc VIP address (192.200.200.200). To prevent server 
source port collisions, the CSS performs Network Address Translation on the 
server's source IP address and port by translating the: Source IP address to the IP 
address defined in the source group" (emphasis added). Accordingly, the Cisco 
document also does not provide the claimed features in claim 34 of (a) "obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address," and (b) "providing, by said site switch, said public virtual IP 
address to at least one load balancing controller." 



Thus, fi-om the above arguments, the Alteon document does not teach a private 
VIP address configured at a switch, and instead teaches a public VIP address configured at a site 
and provided to a client device (rather than to a load balancing controller). With respect to the 
Cisco document, the private IP address 10.0.3.251 of the server taught in the Cisco document 
appears to be a private real address, rather than a private virtual (VIP) address as required by 
claim 67. Furthermore, the private IP address 10.0.3.251 of the Cisco document is configured at a 
server, rather than being configured at a switch as required by claim 67. 
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Pages 13-14 of the Remarks section of the response filed on September 21, 2009 
(in response to the final Office Action of August 3, 2009) provided still further arguments against 
the Examiner as to why the recitations of claim 34 were not taught by the Alteon document and 
the Cisco document. Such arguments are also applicable to claim 67 and are being re-presented 
below (emphasis added) in this Appellant's Brief for further consideration 

"As clearly taught by the Alteon document on page 2 (Figure One), site 
B's virtual IP address is returned "to the client's local DNS" at "3". Thus, since 
the Alteon document teaches returning the virtual IP address to the client's local 
DNS, rather than to at least one load balancing controller, the Alteon document 
does not meet at least the limitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" in claim 34. 

Furthermore, while page 8 (section 7) of the Alteon document mentions 
DSSP (a.k.a. distributed site state protocol, which the Examiner appears to be 
interpreting as some sort of load balancing process), the Alteon document clearly 
teaches on pages 4-5 that DSSP is used by the "DNS authoritative name server" 
and mentions nothing about DSSP being implemented/used by the client's local 
DNS. The "DNS authoritative name server" is clearly not the same as the 
"client's local DNS" that receives site B's virtual IP address at "3." Furthermore, 
a local DNS inherently does not perform load balancing since such a local DNS 
only operates to resolve a domain name for its a local client. Accordingly, it is 
not accurate to interpret the "client's local DNS" as being the same as the "load 
balancing controller" recited in claim 34. 

With regards to the Cisco document, this document was merely cited for 
allegedly teaching translation between public and private virtual IP addresses. 
The Cisco docviment is no more relevant than the Alteon document — both 
documents do not teach the features recited in claim 34." 



Still fijrther, sections 13-14 of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides testimonial evidence as to why a person having knowledge of those skilled 
in the art would believe that the Alteon document and the Cisco document do not teach 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address; and providing, by said 
site switch, said public virtual IP address to at least one load balancing controller." 

Hence, the Alteon document and the Cisco document, whether singly or in 
combination, do not teach the recitations of "identify, by the switch, a public virtual IP address 
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that is mapped to a private virtual IP address configured at the switch; and communicate, by the 
switch to a load balancing controller, the identified public virtual IP address" in claim 67. 
Accordingly, the Examiner's rejection of claim 67 should be withdrawn, since the requirements of 
MPEP § 706.02(j) have not been met: "To support the conclusion that the claimed invention is 
directed to obvious subject matter, either the references must expressly or impliedly suggest the 
claimed invention or the examiner must present a convincing line of reasoning as to why the 
artisan would have found the claimed invention to have been obvious in light of the teachings of 
the references. Ex parte Clapp, 111 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985)" (emphasis 
ours). 

1 0. Dependent claims 68- 70 are non-obvious over the Alteon document and 
the Cisco document 

Rejected dependent claims 68-70 depend directly or indirectly on claim 67, and by 
virtue of this dependency, are non-obvious over the Alteon document and the Cisco document for 
the reasons set forth above with respect to claim 67. 

Furthermore, dependent claim 68 recites, inter alia, "wherein the instructions 
executable by the switch to communicate include instructions executable by the switch to: send, 
by the switch, the identified public virtual IP address to the load balancing controller, which is 
located at the switch " (emphasis ours). Nowhere has the Examiner identified any teaching in the 
Alteon docviment or the Cisco document where the switch communicates the public virtual IP 
address to a load balancing controller located at the switch. Hence, claim 68 is allowable. 

11. Independent claim 71 is non-obvious over the Alteon document and the 
Cisco document 

Independent claim 71 recites, inter alia, the following (emphasis ours): 

"the switch being adapted to identify a public virtual IP address that is 
mapped to the private virtual IP address configured at the switch, and the switch 
being adapted to communicate the identified public virtual IP address to a load 
balancing controller.'''' 
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Such recitations of claim 71 are not taught by the Alteon dociiment and by the 
Cisco document, whether singly or in combination. 

Figure One on page 2 of the Alteon docviment teaches a global server load 
balancing (GSLB) system that includes web switches at sites A-C. After selecting which 
particular site A, B, or C is best suited to serve a client request, the public VIP address of the 
selected site A, B, or C is provided to the client. 

Page 9 (top paragraph) of the final Office Action of August 3, 2009 admits that the 
Alteon document does not teach a "private VIP" address configured at the site switch. To supply 
the missing teachings of the Alteon document, the Examiner relies upon the teachings on page 12 
of the Cisco document. However, the Cisco document does not cure the deficiencies of the 
Alteon document. 

Pages 12-13 of the Cisco document describe the configuration to use a content 
services switch (CSS) to perform network address translation (NAT) to translate a private IP 
address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address (e.g., the 
public VIP address 192.200.200.200) and vice versa. However, the Examiner has failed to show 
where the Cisco document teaches that the private IP address 10.0.3.251 is a virtual IP (VIP) 
address. Instead, it has been argued against the Examiner throughout prosecution that (1) the 
Alteon document does not teach a private virtual IP (VIP) address configured at a switch, and (2) 
the Cisco docviment does not teach that it's private IP address 10.0.3.251 is a private virtual IP 
(VIP) address. 

Page 1 1 of the final Office Action of August 3, 2009 uses the same rationale used 
to reject claim 34 in order to reject claim 71. Pages 12-13 of the Remarks section of the 
amendment filed on April 23, 2009 (in response to the Office Action mailed December 23, 2008) 
provided arguments against the Examiner as to why the recitations of claim 34 were not taught by 
the Alteon docviment and the Cisco docviment. Such arguments are applicable to claim 71 and are 
being re-presented below (emphasis added) in this Appellant's Brief for further consideration: 

"...Figure One and the accompanying description on page 2 of the Alteon 
document describe site switch A that 'returns site B's virtual IP address (VIP) 
address [172.176.110.20] to the client's local DNS.' The local DNS server then 
'responds to client with site B's VIP' and the client 'opens application session to 
IP 172.176.110.20.' Since the VIP address 172.176.110.20 is returned to the 
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client and the client is able to open a session to this VIP address, this means that 
the VIP address 172.176.110.20 is a public VIP address configured at site B 
(described in the Alteon document as 'site B's virtual IP address'). Thus, the 
Alteon document does not describe an implementation involving private VIP 
address configured at the site switch, and therefore it is respectfiiUy submitted that 
the Alteon document does not provide the features in claim [34] of (a) 'obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address,' and (b) 'providing, by said site switch, said public virtual IP 
address to at least one load balancing controller.' 

Pages 12-13 of the Cisco document describe the configuration to use a 
content services switch (CSS) to perform network address translation (NAT) to 
translate a private IP address of a server (e.g., the private IP address 10.0.3.251) to 
a public VIP address (e.g., the public VIP address 192.200.200.200) and vice 
versa. According to Ms. Joshi's reading of the Cisco document, the private IP 
address 10.0.3.251 of the server described in the Cisco document is a private real 
IP address of the server, rather than a private virtual IP address that is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP 
address of a server, rather than a private VIP address configured at a site switch, 
is provided on page 12 of the Cisco document, which states that "The source 
group enables the CSS to perform Network Address Translation to translate 
outbound traffic source IP addresses from the server's private IP address 
(10.0.3.251) to the pubUc VIP address (192.200.200.200). To prevent server 
source port collisions, the CSS performs Network Address Translation on the 
server's source IP address and port by translating the: Source IP address to the IP 
address defined in the source group" (emphasis added). Accordingly, the Cisco 
document also does not provide the claimed features in claim 34 of (a) "obtaining 
at one of said site switches mapping information that provides a translation 
between a private virtual IP address, configured at said site switch and associated 
with said at least one host server corresponding to said site switch, and a public 
virtual IP address," and (b) "providing, by said site switch, said pubUc virtual IP 
address to at least one load balancing controller." 



Thus, fi-om the above arguments, the Alteon document does not teach a private 
VIP address configured at a switch, and instead teaches a public VIP address configured at a site 
and provided to a client device (rather than to a load balancing controller). With respect to the 
Cisco document, the private IP address 10.0.3.251 of the server taught in the Cisco document 
appears to be a private real address, rather than a private virtual (VIP) address as required by 
claim 71. Furthermore, the private IP address 10.0.3.251 of the Cisco document is configured at a 
server, rather than being configured at a switch as required by claim 71 . 
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Pages 13-14 of the Remarks section of the response filed on September 21, 2009 
(in response to the final Office Action of August 3, 2009) provided still further arguments against 
the Examiner as to why the recitations of claim 34 were not taught by the Alteon document and 
the Cisco document. Such arguments are also applicable to claim 71 and are being re-presented 
below (emphasis added) in this Appellant's Brief for further consideration 

"As clearly taught by the Alteon document on page 2 (Figure One), site 
B's virtual IP address is returned "to the client's local DNS" at "3". Thus, since 
the Alteon document teaches returning the virtual IP address to the client's local 
DNS, rather than to at least one load balancing controller, the Alteon document 
does not meet at least the limitation of "providing, by said site switch, said public 
virtual IP address to at least one load balancing controller" in claim 34. 

Furthermore, while page 8 (section 7) of the Alteon document mentions 
DSSP (a.k.a. distributed site state protocol, which the Examiner appears to be 
interpreting as some sort of load balancing process), the Alteon document clearly 
teaches on pages 4-5 that DSSP is used by the "DNS authoritative name server" 
and mentions nothing about DSSP being implemented/used by the client's local 
DNS. The "DNS authoritative name server" is clearly not the same as the 
"client's local DNS" that receives site B's virtual IP address at "3." Furthermore, 
a local DNS inherently does not perform load balancing since such a local DNS 
only operates to resolve a domain name for its a local client. Accordingly, it is 
not accurate to interpret the "client's local DNS" as being the same as the "load 
balancing controller" recited in claim 34. 

With regards to the Cisco document, this document was merely cited for 
allegedly teaching translation between public and private virtual IP addresses. 
The Cisco docviment is no more relevant than the Alteon document — both 
documents do not teach the features recited in claim 34." 



Still fijrther, sections 13-14 of Ms. Joshi's affidavit executed on October 2, 2008 
(Exhibit A) provides testimonial evidence as to why a person having knowledge of those skilled 
in the art would believe that the Alteon document and the Cisco document do not teach 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address; and providing, by said 
site switch, said pubhc virtual IP address to at least one load balancing controller." 

Hence, the Alteon dociament and the Cisco document, whether singly or in 
combination, do not teach the recitations of "the switch being adapted to identify a public virtual 
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IP address that is mapped to the private virtual IP address configured at the switch, and the switch 
being adapted to communicate the identified public virtual IP address to a load balancing 
controller" in claim 71. Accordingly, the Examiner's rejection of claim 71 should be withdrawn, 
since the requirements of MPEP § 706.02(j) have not been met: "To support the conclusion that 
the claimed invention is directed to obvious subject matter, either the references must expressly or 
impliedly suggest the claimed invention or the examiner must present a convincing line of 
reasoning as to why the artisan would have found the claimed invention to have been obvious in 
light of the teachings of the references. Ex parte Clapp, 111 USPQ 972, 973 (Bd. Pat. App. & 
Inter. 1985)" (emphasis ours). 

12. Dependent claims 72-74 are non-obvious over the Alteon document and 

the Cisco document 

Rejected dependent claims 72-74 depend directly or indirectly on claim 71, and by 
virtue of this dependency, are non-obvious over the Alteon document and the Cisco docviment for 
the reasons set forth above with respect to claim 71. 

Furthermore, dependent claim 72 recites, inter alia, "wherein the load balancing 
controller is included in the switch " (emphasis ours). Nowhere has the Examiner identified any 
teaching in the Alteon document or the Cisco document where the switch communicates the 
public virtual IP address to a load balancing controller included in the switch. Hence, claim 72 is 
allowable. 

In view of the arguments as set forth above, the Examiner's rejections of the 
claims should be withdrawn. 

Respectfully submitted, 
Schwabe, Williamson & Wyatt 

/Dennis M. de Guzman/ 
Dennis M. de Guzman 
Registration No. 41,702 



1420 Fifth Avenue, Suite 3010 
Seattle, Washington 98101 
Phone: (206)407-1574 
Fax: (206)292-0460 
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VIII. CLAIMS APPENDIX 

In accordance with 37 CFR 41.37(c)(l)(viii), provided herewith is an appendix 
containing a copy of the "claims involved in the appeal." It is noted herein that canceled claims 
1-33, 39-42, 47-50, and 56-59 are not "involved in the appeal", and therefore 
37 CFR41.37(c)(l)(viii) does not require a copy of these canceled claims to be included in the 
claim listing below: 

34. (Previously Presented) A method of providing load balancing usable with 
a load balance switch and a plurality of site switches that are each adapted to couple at least one 
host server to a network, the method comprising: 

obtaining at one of said site switches mapping information that provides a 
translation between a private virtual IP address, configured at said site switch and associated with 
said at least one host server corresponding to said site switch, and a public virtual IP address; and 

providing, by said site switch, said public virtual IP address to at least one load 
balancing controller. 

35. (Previously Presented) The method of claim 34 wherein said providing, by 
said site switch, said public virtual IP address to said at least one load balancing controller 
includes providing by said site switch said public virtual IP address to a load balancing controller 
located at said load balance switch. 

36. (Previously Presented) The method of claim 35 wherein said providing, by 
said site switch, said public virtual IP address to said at least one load balancing controller further 
includes providing by said site switch said public virtual IP address to a load balancing controller 
located at said site switch, to enable said site switch to balance traffic among plural ones of said at 
least one host server corresponding to said site switch and associated with said private virtual IP 
address. 
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37. (Previously Presented) The method of claim 34 wherein public virtual IP 
addresses received by said load balancing controller as part of reply to a query for network 
addresses and that do not have indication in an address record as being associated with 
corresponding said site switches, are treated as real IP addresses by said load balancing controller 
and are excluded from having applied thereto any mefric of a load balancing algorithm that is 
usable with virtual IP addresses. 

38. (Previously Presented) The method of claim 34 wherein said public virtual 
IP address provided to said at least one load balancing controller enables said load balancing 
controller to apply at least one metric of a load balancing algorithm to said public virtual IP 
address, said at least one metric including an active bindings metric that prefers a virtual IP 
address, configured at respective said site switches, having a maximum number of active ones of 
said host servers bound to said preferred virtual IP address, rather than preferring another virtual 
IP address having a number of bound active ones of said host servers that is less than said 
maximum number. 

43. (Previously Presented) An article of manufacture, comprising: 

a storage medivim at a site switch and having instructions stored thereon that are 
executable by said site switch to enable load balancing, by: 

obtaining at said site switch mapping information that provides a translation 

between a private virtual IP address and a public virtual IP address, said private virtual IP address 
being configured at said site switch and being associated with at least one host server 
corresponding to said site switch; and 

providing, by said site switch, said public virtual IP address to at least one load 
balancing confroUer. 

44. (Previously Presented) The article of manufacture of claim 43 wherein the 
instructions to provide, by said site switch, said public virtual IP address to said at least one load 
balancing controller includes instructions to provide by said site switch said public virtual IP 
address to a load balancing controller located at said load balance switch. 
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45. (Previously Presented) The article of manufacture of claim 43 wherein the 
instructions to provide, by said site switch, said public virtual IP address to said at least one load 
balancing controller includes instructions to provide by said site switch said public virtual IP 
address to a load balancing controller located at said site switch, to enable said site switch to 
balance traffic among plural ones of said at least one host server corresponding to said site switch 
and associated with said private virtual IP address. 

46. (Previously Presented) The article of manufacture of claim 43 wherein said 
public virtual IP address provided to said at least one load balancing controller enables said load 
balancing controller to apply at least one metric of a load balancing algorithm to said public 
virtual IP address, said at least one metric including an active bindings metric that prefers a virtual 
IP address, configured at respective said site switches, having a maximum number of active ones 
of said host servers bound to said preferred virtual IP address, rather than preferring another 
virtual IP address having a number of bound active ones of said host servers that is less than said 
maximum number. 

5 1 . (Previously Presented) A network device, comprising: 

a site switch configurable with a private virtual IP address associated with at least 
one host server corresponding to said site switch; and 

a component in said site switch to obtain a public virtual IP address translated from 
said private virtual IP address, 

wherein said site switch is adapted to provide said obtained public virtual IP 
address to at least one load balancing controller. 

52. (Previously Presented) The network device of claim 51 wherein said at 
least one load balancing controller includes a load balancing controller located at a load balance 

switch remote from said site switch. 

53. (Previously Presented) The network device of claim 51 wherein said at 
least one load balancing controller includes a load balancing controller located at said site switch 
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and adapted to balance traffic among plural ones of said at least one host server corresponding to 
said site switch and associated with said private virtual IP address. 

54. (Previously Presented) The network device of claim 51 wherein public 
virtual IP addresses received by said load balancing controller as part of reply to a query for 
network addresses and that do not have indication in an address record as being associated with a 
corresponding one of a plurality of said site switch, are treated as real IP addresses by said load 
balancing controller and are excluded from having applied thereto any metric of a load balancing 
algorithm that is usable with virtual IP addresses. 

55. (Previously Presented) The network device of claim 51 wherein said 
public virtual IP address provided to said at least one load balancing controller enables said load 
balancing controller to apply at least one metric, usable with virtual IP addresses, of a load 
balancing algorithm to said public virtual IP address, said at least one metric including an active 
bindings metric that prefers a virtual IP address, configured at respective plural ones of said site 
switch, having a maximum number of active ones of said host servers bound to said preferred 
virtual IP address, rather than preference of another virtual IP address having a number of bound 
active ones of said host servers that is less than said maximum number. 

60. (Previously Presented) The method of claim 34 wherein said obtaining at 

said site switch said mapping information includes obtaining at said site switch said mapping 
information from a mapping device that includes a network address translation device or a 
firewall device. 

61 . (Previously Presented) The article of manufacture of claim 43 wherein said 
instructions to obtain at said site switch said mapping information includes instructions to obtain 
at said site switch said mapping information from a mapping device that includes a network 
address translation device or a firewall device. 
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62. (Previously Presented) The network device of claim 51 wherein said 
component in said site switch is adapted to obtain said public virtual IP address from a mapping 
device that includes a network address translation device or a firewall device. 

63. (Previously Presented) A method of providing load balancing, the method 

comprising: 

identifying, by a switch, a public virtual IP address that is mapped to a private 
virtual IP address configured at the switch; and 

communicating, by the switch to a load balancing controller, the identified public 
virtual IP address. 

64. (Previously Presented) The method of claim 63 wherein said 
communicating includes: 

sending, by the switch, the identified public virtual IP address to the load balancing 
controller, which is located at the switch. 

65. (Previously Presented) The method of claim 63 wherein said identifying 
the public virtual IP address that is mapped to the private virtual IP address includes: 

identifying, by the switch, the public virtual IP address from mapping information 
internally stored in the site switch. 

66. (Previously Presented) The method of claim 63 wherein said identifying 
the public virtual IP address that is mapped to the private virtual IP address includes: 

identifying, by the switch, the public virtual IP address from mapping information 
externally received by the site switch. 

67. (Previously Presented) An article of manufacture, comprising: 

a storage medium at a switch and having instructions stored thereon that are 
executable by the switch to: 
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identify, by the switch, a public virtual IP address that is mapped to a private 
virtual IP address configured at the switch; and 

communicate, by the switch to a load balancing controller, the identified public 
virtual IP address. 

68. (Previously Presented) The article of manufacture of claim 67 wherein the 
instructions executable by the switch to communicate include instructions executable by the 
switch to: 

send, by the switch, the identified public virtual IP address to the load balancing 
controller, which is located at the switch. 

69. (Previously Presented) The article of manufacture of claim 67 wherein the 
instructions executable by the switch to identify the public virtual IP address that is mapped to the 
private virtual IP address include instructions executable by the switch to: 

identify, by the switch, the public virtual IP address from mapping information 
internally stored in the site switch. 

70. (Previously Presented) The article of manufacture of claim 67 wherein the 
instructions executable by the switch to identify the public virtual IP address that is mapped to the 
private virtual IP address include instructions executable by the switch to: 

identify, by the switch, the public virtual IP address from mapping information 

externally received by the site switch . 

71 . (Previously Presented) A network device, comprising: 

a switch configurable with a private virtual IP address, the switch being adapted to 

identify a public virtual IP address that is mapped to the private virtual IP address configured at 
the switch, and the switch being adapted to communicate the identified public virtual IP address 
to a load balancing controller. 
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72. (Previously Presented) The network device of claim 71 wherein the load 
balancing controller is included in the switch. 

73. (Previously Presented) The network device of claim 71 wherein the switch 
is adapted to said identify the public virtual IP address from mapping information internally 
stored in the switch. 

74. (Previously Presented) The network device of claim 71 wherein the switch 
is adapted to said identify the public virtual IP address from mapping information externally 
received by the site switch. 
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IX. EVIDENCE APPENDIX 

In accordance with 37 CFR 41.37(c)(l)(ix), provided herewith is an appendix 
containing copies of any evidence submitted pursuant to 37 CFR 1.130, 1.131, or 1.132 or of any 
other evidence entered by the examiner and relied upon in this appeal. In particular, a copy of an 
affidavit of Ms. Prajakta S. Joshi executed on October 2, 2008 (Exhibit A) and a copy of an 
affidavit of Ms. Joshi executed on January 29, 2008 (Exhibit B) are provided in this Evidence 
Appendix in the pages that follow. 

Ms. Joshi's affidavit executed on October 2, 2008 (Exhibit A) was entered in the 
record when it was filed on October 7, 2008, along with an amendment and a Request for 
Continued Examination (RCE). Further confirmation that such communication(s) was 
acknowledged/entered by the Examiner can be found in the Office Action Summary Page of the 
Office Action of December 23, 2008, which indicated: "Status 1)... Responsive to 
communication(s) filed 07 October 2008." Ms. Joshi's affidavit executed on October 2, 2008 was 
fijrther confirmed as being in the record by virtue of the Examiner's presentation of arguments 
against said affidavit in said Office Action of December 23, 2008 (page 2, first and second 
paragraphs of section 2; page 4, lines 11-15; page 5, lines 8-10), in the final Office Action of 
August 3, 2009 (pages 2-3, first through fourth paragraphs of section 3; page 3, last paragraph), 
and in the Advisory Action of October 16, 2009 (last sentence on the continuation sheet). 

Ms. Joshi's affidavit executed on January 29, 2008 (Exhibit B) was entered in the 
record when it was filed on January 30, 2008, along with an amendment in response to a non-final 
Office Action mailed on July 30, 2007. Further confirmation that such communication(s) was 
acknowledged/entered by the Examiner can be found in the Office Action Summary Page of the 
Office Action of April 11, 2008, which indicated: "Status 1)... Responsive to communication(s) 
filed 30 January 2008." 

See the pages that follow for copies of the affidavits of Exhibits A and B. 
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PRIVATE VIP ADDRESSES 

Examiner : Ted T. Vo 

Art Unit : 2191 

Docket No. 350078.409 
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Mail Stop RCE 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

AFFIDAVIT OF PRAJAKTA S. JOSHI 

Commissioner for Patents: 

1. My name is Prajakta S. Joshi, and I have the mailing address indicated 

below: 

Prajakta S. Joshi 
Foundry Networks, Inc. 
4980 Great America Parkway 
Santa Clara, California 95054 
United States 

2. I am an original, first, and sole inventor of the subject matter that is 
claimed in and for which a patent is sought by U.S. Patent Application Serial No. 10/674,627 
identified above (the "present application"). 
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3 . I am currently employed as a software engineer at Foundry Networks, Inc. 
(the assignee of the present application), and have been employed at Foundry Networks, Inc. 
since approximately April 2002. 

4. My employment duties include the design, testing, and implementation of 
products and features for Foundry Networks, Inc.'s Global Server Load Balancing (GSLB) 
technology, to which the subject matter of the present application is directed. 

5. My educational background includes a Bachelor's of Engineering from 
University of Pune in India in 1998 and a Masters of Computer Science from the University of 
Southem Califomia in 1999. 

6. Based on my educational and industry experience described above, I am 
knowledgeable of the subject matter described in Foundry Networks, Inc.'s white paper entitled 
"Server Load Balancing in Today's Web-Enabled Enterprise" (hereinafter "the White Paper"), 
the Alteon WebSystems, Inc. document entitled "Enhancing Web User Experience with Global 
Server Load Balancing (hereinafter "the Alteon docimient"), and the Cisco Systems Inc. 
document entitled "Configuring the CSS Domain Name Service (hereinafter "the Cisco 
document"), which have been cited by the U.S. Patent Office against the claims in the present 
application. 

7. I have read and understand the subject matter described in the White 
Paper, the Alteon document, and the Cisco document. 

8. Page 6 et seq. of the White Paper describes operation of Foundry 
Networks, Inc.'s GSLB technology that existed before my invention as presently claimed in the 
present application. The present claims distinguish over this GSLB technology. Specifically, 
with the GSLB technology that existed at the time of the White Paper, for an implementation 
where a private virtual IP address is configured at a site switch (such as at the site switch in San 
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Francisco shown in the figure on page 6 of the White Paper) and where such private virtual IP 
address was mapped to a public virtual IP address, this site switch would not be aware of this 
mapping and would communicate the private virtual IP address configured thereon to the load 
balance switch (shown as the controller GSLB switch or "CGS" in the figure in page 6 of the 
White Paper). What I am claiming in the present application is different, as described later 
below. 

9. Figure A below further illustrates by way of example the GSLB 
technology of the White Paper, for an implementation where a VIP's private IP address ("private 
VIP address") is configured at a site switch. The real IP addresses of Host Server 1 and Host 
Server 2 (e.g., real IP addresses 10.10.10.1 and 10.10.10.2 respectively) are associated with a 
private VIP address {e.g., private VIP address 10.10.10.3) that is configured at Site Switch 1 . 
Site Svidtch 1 provides/reports this private VIP address 10.10.10.3 configured thereon to the 
CGS. The CGS (GSLB switch controller) provides GSLB for a domain www.foo.com (for 
example). The domain www.foo.com is serviced by the VIP's public IP address ("public VIP 
address"), such as a public VIP address 1 92. 1 68. 1 0. 1 . An authoritative DNS server for the 
domain ymw.foo.com provides/reports the public VIP address (e.g., the public VIP address 
192.168.10.1 that maps/translates to the private VIP address 10.10.10.3) to the CGS. Site Switch 
1 (and the other site switches in the figure in page 6 of the White Paper) was not aware of the 
translation/mapping of the private VIP address 10.10.10.3 configured thereon to the public VIP 
address 192.168.10.1. 
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Figure A 



10. Communication by the site switch of the private virtual IP address (e.g., 
10.10.10.3) configured thereon to the load balance switch (CGS) caused certain problems in the 
use of a load balancing algorithm by the load balance switch of the White Paper. For example, 
the load balance switch would not be able to match the private VIP address (e.g., 10.10.10.3) 
received from the site switch with the public VIP address (e.g., 192.168.10.1) received from the 
DNS server. These problems are further explained on pages 2-4 of the present application. 



11. To address such problems, the embodiments described in the present 
application provided the following example features: (a) obtaining, by the site switch, mapping 
information that provided a translation between a private virtual IP address configured at that site 
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switch and a public virtual IP address, and (b) providing, by the site switch, the public virtual IP 
address to a load balancing controller. Figure B below illustrates by way of example the 
operation of my embodiment(s) disclosed in the present application. 



NAT 
Device 



CONTROLLER/CGS 
{providing GSLB for 
www.foo.com) 



Report 
192.168.10.1 
(Public VIP address) 



Authoritative DNS 
server for domain 
www.A3o.com (domain 
www.fi3o.com serviced 
by public IP address 
192.168.10.1) 







+ 






Provide 192.168.10.1 1 
{VIP's public IP address) as mapping for | 
10,10.10.3 {VIP's private IP address) | 


1 Report 

1 192.168.10.1 

[{Public VIP address) 




Private VIP 
address configured 
at site switch lis 
10.10.10.3 


SITE SWITCH 1 
(San Francisco) 




SITE SWITCH 2 
(Hong Kong) 



Real (Host) 
Server 1 



Real IP address 
10.10.10.1 



Real (Host) 
Server 2 



Real IP address 
10.10.10.2 



Figure B 



12, As can be seen in Figure B above, Site Switch 1 has a private VIP address 
(e.g., the private VIP address 10.10.10.3) configured thereon, and obtains from a mapping 
device, such as a network address translation (NAT) device, the public VIP address (e.g., the 
public VIP address 192.168.10.1) that maps/translates to the private VIP address 10.10.10.3— the 
NAT device provides 192.168.10.1 (the VIP's public IP address) as mapping for 10.10.10.3 (the 
VIP's private IP address). As such. Site Switch 1 is able to provide the public VIP address 
192.168.10.1 to the CGS. The CGS in turn is able to successfully match the public VIP address 
192.168.10.1 provided by Site Switch 1 with the public VIP address 192.168.10.1 provided by 
the DNS server. Accordingly, the claims of the present application distinguish over the GSLB 
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technology described in the White Paper, by including the following claim terms (in claim 1 for 
example) that are not shown or described by the GSLB technology in the White Paper: 
"obtaining at one of said site switches mapping information that provides a translation between a 
private virtual IP address, configured at said site switch and associated with said at least one host 
server corresponding to said site switch, and a public virtual IP address" and "providing, by said 
site switch, said public virtual IP address to at least one load balancing controller." 

1 3. The U.S. Patent Ojffice has also cited the Alteon document against the 
claims in the present application. Figure One and the accompanying description on page 2 of the 
Alteon document describe site switch A that "returns site B's virtual IP address (VIP) address 
[172. 176. 11 0.20] to the client's local DNS." The local DNS server then "responds to client with 
site B's VIP" and the client "opens application session to IP 172.176.1 10.20." Since the VIP 
address 172,176.1 10.20 is returned to the client and the client is able to open a session to this 
VIP address, this means that the VIP address 172.176.1 10.20 is a public VIP address configured 
at site B (described in the Alteon document as "site B's virtual IP address"). Thus, the Alteon 
document does not describe an implementation involving private VIP address configured at the 
site switch, and therefore the Alteon document in my view does not provide the claimed features 
(such as in claim 1) of (a) "obtaining at one of said site switches mapping information that 
provides a translation between a private virtual IP address, configured at said site switch and 
associated with said at least one host server corresponding to said site switch, and a public virtual 
IP address," and (b) "providing, by said site switch, said public virtual IP address to at least one 
load balancing controller." 

14. The U.S. Patent Office has also cited the Cisco document against the 
claims in the present application. Pages 12-13 of the Cisco document describe the configuration 
to use a content services switch (CSS) to perform network address translation (NAT) to translate 
a private IP address of a server (e.g., the private IP address 10.0.3.251) to a public VIP address 
(e.g., the public VIP address 192.200.200.200) and vice versa. According to my reading of the 
Cisco document, the private IP address 10.0.3.251 of the server described in the Cisco document 
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is a private real IP address of the server, rather than a private virtxjal IP address liiat is configured 
at a site switch. Evidence that the private IP address 10.0.3.251 is a real IP address of a server, 
rather than a private VIP address configured at a site switch, is provided on page 12 of the Cisco 
document, which states that "The source group enaWes the CSS to perform Network Address 
Translation to translate outbound ti:afGc source IP addresses fhim the server's private W address 
0 0.0.3.251) to the public VIP address (192.200.200.200). To prevent server source port 
collisions, the CSS performs Network Address Translation on the server's source IP address and 
port by translating the: Source IP address to the IP address defined in the source 
group" (emphasis added). Accordingly, the Cisco document also does not provide the claimed 
features (such as in claim 1) of (a) "obtaining at one of said site switches mapping information 
that provides a translation between a private virtual IP address, configured at said site switch and 
associated with said at least one host server corresponding to said site switch, and a public virtual 
IP address," and (b) '*providing, by said site switch, said public virtual IP address to at least one 
load balancing controller " 



15. I declare that all statements made herein of ray own knowledge are true 



and that all statements made on information and belief are believed to be true. I make these 
statements with the knowledge that wilful false statements and the like are punishable by fme or 
imprisonment, or both (1 8 U.S.C. 1001) and may jeopardize the validity of the present 
application or any patent issuing thereon. 
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Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



AFFIDAVIT OF PRAJAKTA S. JOSHI 



Commissioner for Patents: 



1. My name is Prajaicta S. Joshi, and I have the mailing address indicated 

below: 

Prajakta S. Joshi 
FoufldryNetworics, Inc. 
4980 Great America Parkway 
Santa Clara, California 95054 
United States 



2. I am an origind, firsthand sole inventor of the subj^^ 
claimed in and for which a patent is soifgbt by U,S, Patent Application Serial No, 10/6f74i62? ^' V!V!' . ^ • 
identii&ed above (the "present application"). ■ ^ 

[exhibit b| 



JAN-29-2008 TUE 04:57 PM FOUNDRY NETWORKS 



FAX NO. 4082071459 



P. 02 



Application No. 10/674,627 
Affidavit of Prajakta S. Joshi 

3. . I am ciin^ently employed as a software engineer in the LayCT^ 
Foundry Networks, Inc. (the assignee of the present applficatibn), and have been employed at 
Foundiy Networks, Inc. since approximately April 2002. 

4. My employment duties include the design, testing, and implementation of 
products and features for Foundry Networks, Inc's Global Server Load Balancing (GSLB) 
technology, to which the subject matter of the present application is directed. 

5. My educational background includes a Bachelor's of Engineering &om 
University of Pune in India in 1998 and a Masters of Computer Science from the University of 
Southern California in 1999. 

6. Based on my educational and industry experience described above, I 
consider myself to be knowledgeable of the subject matter described in Foundry Networks, Inc's 
white paper entitled "Server Load Balancing in Today's Web-Enabled Enterprise" (hereinafter 
"the White Paper"), which has been cited by the U.S. Patent Office against the dairas in the 
present application. 

7. I have read and understand the subject matter described in the White 

Paper. 

8. Page 6 et seq. of the White Paper describes operation of Foundry Network,. 
Inc.'s GSLB technology that does not inciude implementation ofmy invention as claimed in the : i, . v 
present application. Sperafically, from tte April 2002 date of the WMte Paper up toi the date iv. i, c / ; ;i i;. ? 
before my invention, for a situation where a private virtual IP adc^s is; configured at a.site \ . i . ; • ;,in . o \ i 
switch (such as at the site switch in Hon^ Kong] slw>wn ih^.t^^ of the^WMte lie i;g Kong ^ho)vi 
Paper) and where such private virtual dddresswas 'majiped, ta a public virtuM.IPi address^, the ; ' ■v.'J. I'css yqii.i 
site switch would not be aware of this mapping dnd woiild cpminimicate the private virtual' IP < < ■ i i n ; , i i v.4 ■ : i ■ i M u 
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address configured thereon to the load balance switch (shown as the controller GSLB switch. or .^i 
"CGS" in the figure in page 6 of the White Paper). ; . V ' ' ' 

9. Communication of the private virtual IP address to the load balance switch 
(CGS) caused certain problems in the use of a load balancing algorithm by the load balance 
switch of the White Paper. These problems are explained on pages 2-4 of the present 
application. 

1 0. I was assigned with the task of solving such problems. To address such 
problems, the embodiments of my invention described in the present application provided the 
following example features: (a) obtained, by the site switch, mapping information that provided a 
translation between a private virtual IP address configured at that site switch and a public virtual 
IP address, (b) provided the public virtual IP address from the site switch to the load balance 
switch, (c) the load balance switch updated an address record to indicate the public virtual IP 
address as being associated with the site switch. 

11. At least these features of the embodiments of my invention were not 
present in the implementation of the GSLB technology described in the White P^er. For 
example and before my invention for an implementation involving a private vu^ual IP address 
configured at a site switch and mapped to a public virtual IP address, the site switch in Hong 
Kong (shown in the figure on page 6 of the White Paper) did not receive such mapping . 
information from a mapping device (such fix)m as a netwoik address translation device or . ; ' . 
firewall), and therefore, such site switch in Hong Kong would not have communicated the public ; t ?. 
virtual IP address to the load balance sWitcih, commumcating instead the private: virtual.IP.ii : s, ',j -ic , ! i;; 
address.. ' ■^■;/.:>jilire;;i:. : i . 

12. - I declare that ail statements made heran of 

and that all statements made on information and belief areVbeiievedlto betniiei-!lTnafce:these't m i^ion intii h-sll^.i 
statements with the knowledge that willful false statements and the like are punishable by fine or : . . 
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iraprisomnent, or both.(18 U.S.C. 1001) and may jeopardize the validity of ih^ 
patent issuing thereon. . . . ; : . . 
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